Plattformübergreifende Kryptografie in .NET Core und .NET 5

Kryptografische Vorgänge in .NET Core und .NET 5+ werden von Betriebssystembibliotheken (Betriebssystem) durchgeführt. Diese Abhängigkeit hat Vorteile:

  • .NET-Apps profitieren von der Zuverlässigkeit des Betriebssystems. Die Sicherheit von Kryptografiebibliotheken vor Sicherheitsrisiken ist eine hohe Priorität für Betriebssystemanbieter. Dazu stellen sie Updates bereit, die Systemadministratoren anwenden sollten.
  • .NET-Apps haben Zugriff auf FIPS-validierte Algorithmen, wenn die Betriebssystembibliotheken FIPS-überprüft sind.

Die Abhängigkeit von Betriebssystembibliotheken bedeutet auch, dass .NET-Apps nur kryptografische Features verwenden können, die das Betriebssystem unterstützt. Während alle Plattformen bestimmte Kernfeatures unterstützen, können einige Features, die .NET unterstützt, nicht auf einigen Plattformen verwendet werden. In diesem Artikel werden die Features identifiziert, die auf jeder Plattform unterstützt werden.

In diesem Artikel wird davon ausgegangen, dass Sie mit kryptografischer Kryptografie in .NET vertraut sind. Weitere Informationen finden Sie unter .NET-Kryptografiemodell und .NET-Kryptografiedienste.

Hashalgorithmen

Alle Hashalgorithmus- und Hash-basierten Nachrichtenauthentifizierungsklassen (HMAC), einschließlich der *Managed Klassen, verschieben sie auf die Betriebssystembibliotheken. Während sich die verschiedenen Betriebssystembibliotheken in der Leistung unterscheiden, sollten sie kompatibel sein.

Symmetrische Verschlüsselung

Die zugrunde liegenden Verschlüsselungen und Verketteungen werden von den Systembibliotheken durchgeführt, und alle werden von allen Plattformen unterstützt.

Cipher + Modus Windows Linux macOS
AES-CBC ✔️ ✔️ ✔️
AES-EZB ✔️ ✔️ ✔️
3DES-CBC ✔️ ✔️ ✔️
3DES-EZB ✔️ ✔️ ✔️
DES-CBC ✔️ ✔️ ✔️
DES-EZB ✔️ ✔️ ✔️

Authentifizierte Verschlüsselung

Authentifizierte Verschlüsselung (AE) wird für AES-CCM und AES-GCM über die System.Security.Cryptography.AesCcm und System.Security.Cryptography.AesGcm Klassen bereitgestellt.

Auf Windows und Linux werden die Implementierungen von AES-CCM und AES-GCM von den Betriebssystembibliotheken bereitgestellt.

AES-CCM und AES-GCM auf macOS

Auf macOS unterstützen die Systembibliotheken AES-CCM oder AES-GCM für Drittanbietercode nicht, sodass die AesCcm und AesGcm Klassen OpenSSL für den Support verwenden. Benutzer auf macOS müssen eine entsprechende Kopie von OpenSSL (libcrypto) für diese Typen abrufen, und es muss sich in einem Pfad befinden, in dem das System standardmäßig eine Bibliothek lädt. Es wird empfohlen, OpenSSL aus einem Paket-Manager wie Homebrew zu installieren.

libcrypto.0.9.8.dylib Die libcrypto.0.9.7.dylib in macOS enthaltenen Bibliotheken stammen aus früheren Versionen von OpenSSL und werden nicht verwendet. Die libcrypto.35.dylib, libcrypto.41.dylib, und libcrypto.42.dylib Bibliotheken sind von LibreSSL und werden nicht verwendet.

AES-CCM-Schlüssel, Nonces und Tags

  • Schlüsselgrößen

    AES-CCM funktioniert mit 128, 192 und 256-Bit-Tasten.

  • Nonce-Größen

    Die AesCcm Klasse unterstützt 56, 64, 72, 80, 88, 96 und 104-Bit (7, 8, 9, 10, 11, 12 und 13 Byte) Nonces.

  • Taggrößen

    Die AesCcm Klasse unterstützt das Erstellen oder Verarbeiten von 32, 48, 64, 80, 96, 112 und 128-Bit -Tags (4, 8, 10, 12, 14 und 16-Byte).

AES-GCM-Schlüssel, Nonces und Tags

  • Schlüsselgrößen

    AES-GCM funktioniert mit 128, 192 und 256-Bit-Tasten.

  • Nonce-Größen

    Die AesGcm Klasse unterstützt nur 96-Bit(12-Byte)-Nonces.

  • Taggrößen

    Die AesGcm Klasse unterstützt das Erstellen oder Verarbeiten von 96, 104, 112, 120 und 128-Bit -Tags (12, 13, 14, 15 und 16 Byte).

Asymmetrische Kryptografie

Dieser Abschnitt enthält die folgenden Unterabschnitte:

RSA

RSA (Rivest–Shamir–Adleman) wird von den Betriebssystembibliotheken durchgeführt und unterliegt ihren Größenbeschränkungen und Leistungseigenschaften.

RSA-Schlüsselvorgänge werden von den Betriebssystembibliotheken ausgeführt, und die Typen von Schlüsseln, die geladen werden können, unterliegen den Betriebssystemanforderungen.

.NET stellt keine "unformatierten" (unpaddierten) RSA-Vorgänge zur Verfügung.

Die Betriebssystembibliotheken werden für verschlüsselungs- und Entschlüsselungsabstand verwendet. Nicht alle Plattformen unterstützen die gleichen Abstandsoptionen:

Abstandsmodus Windows (CNG) Linux (OpenSSL) macOS Windows (CAPI)
PKCS1-Verschlüsselung ✔️ ✔️ ✔️ ✔️
OAEP - SHA-1 ✔️ ✔️ ✔️ ✔️
OAEP - SHA-2 (SHA256, SHA384, SHA512) ✔️ ✔️ ✔️
PKCS1 Signature (MD5, SHA-1) ✔️ ✔️ ✔️ ✔️
PKCS1 Signature (SHA-2) ✔️ ✔️ ✔️ ⚠️*
PSS ✔️ ✔️ ✔️

* Windows CryptoAPI (CAPI) ist in der Lage, PKCS1-Signatur mit einem SHA-2-Algorithmus zu erstellen. Das einzelne RSA-Objekt kann jedoch in einem kryptografischen Dienstanbieter (CSP) geladen werden, das es nicht unterstützt.

RSA auf Windows

  • Windows CryptoAPI (CAPI) wird immer verwendet, wenn new RSACryptoServiceProvider() sie verwendet wird.
  • Windows Kryptografie-API Next Generation (CNG) wird immer verwendet, wenn new RSACng() sie verwendet wird.
  • Das von Windows CNG zurückgegebene RSA.Create Objekt wird intern unterstützt. Diese Verwendung von Windows CNG ist ein Implementierungsdetails und unterliegt änderungen.
  • Die GetRSAPublicKey Erweiterungsmethode für X509Certificate2 die Rückgabe einer RSACng Instanz. Diese Verwendung RSACng ist ein Implementierungsdetails und unterliegt änderungen.
  • Die GetRSAPrivateKey Erweiterungsmethode für X509Certificate2 derzeit bevorzugt eine RSACng Instanz, aber wenn RSACng der Schlüssel nicht geöffnet werden kann, RSACryptoServiceProvider wird versucht. Der bevorzugte Anbieter ist ein Implementierungsdetails und unterliegt änderungen.

RSA native Interop

.NET stellt Typen bereit, mit denen Programme mit den Betriebssystembibliotheken interoperiert werden können, die der .NET-Kryptografiecode verwendet. Die beteiligten Typen übersetzen nicht zwischen Plattformen und sollten nur bei Bedarf direkt verwendet werden.

type Windows Linux macOS
RSACryptoServiceProvider ✔️ ⚠(1) ⚠(1)
RSACng ✔️
RSAOpenSsl ✔️ ⚠^2

1 Unter macOS und Linux RSACryptoServiceProvider kann für die Kompatibilität mit vorhandenen Programmen verwendet werden. In diesem Fall löst jede Methode, die betriebssysteminterne Interop erfordert, z. B. das Öffnen eines benannten Schlüssels, eine PlatformNotSupportedException.

2 Auf macOS funktioniert es, RSAOpenSsl wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das laden der dynamischen Bibliothek gefunden werden kann. Wenn eine entsprechende Bibliothek nicht gefunden werden kann, werden Ausnahmen ausgelöst.

ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) wird von den Betriebssystembibliotheken erstellt und unterliegt ihren Größenbeschränkungen und Leistungseigenschaften.

ECDSA-Schlüsselkurven werden von den Betriebssystembibliotheken definiert und unterliegen ihren Einschränkungen.

Elliptische-Kurven- Windows 10 Windows 7 - 8.1 Linux macOS
NIST P-256 (secp256r1) ✔️ ✔️ ✔️ ✔️
NIST P-384 (secp384r1) ✔️ ✔️ ✔️ ✔️
NIST P-521 (secp521r1) ✔️ ✔️ ✔️ ✔️
Brainpool-Kurven (wie benannte Kurven) ✔️ ⚠(1)
Andere benannte Kurven ⚠^2 ⚠(1)
Explizite Kurven ✔️ ✔️
Exportieren oder Importieren als explizit ✔️ 3 ✔️ 3

1 Linux-Verteilungen verfügen nicht über Unterstützung für dieselben benannten Kurven.

2 Unterstützung für benannte Kurven wurde Windows CNG in Windows 10 hinzugefügt. Weitere Informationen finden Sie unter CNG Named Elliptic Curves. Benannte Kurven sind in früheren Versionen von Windows nicht verfügbar, außer für drei Kurven in Windows 7.

3 Das Exportieren mit expliziten Kurvenparametern erfordert die Unterstützung der Betriebssystembibliothek, die auf macOS oder früheren Versionen von Windows nicht verfügbar ist.

ECDSA Native Interop

.NET stellt Typen bereit, mit denen Programme mit den Betriebssystembibliotheken interoperiert werden können, die der .NET-Kryptografiecode verwendet. Die beteiligten Typen übersetzen nicht zwischen Plattformen und sollten nur bei Bedarf direkt verwendet werden.

type Windows Linux macOS
ECDsaCng ✔️
ECDsaOpenSsl ✔️ ⚠️*

* Funktioniert auf macOS, ECDsaOpenSsl wenn OpenSSL im System installiert ist und eine entsprechende libcrypto dylib über das laden der dynamischen Bibliothek gefunden werden kann. Wenn eine entsprechende Bibliothek nicht gefunden werden kann, werden Ausnahmen ausgelöst.

ECDH

ECDH (Elliptic Curve Diffie-Hellman) wird von den Betriebssystembibliotheken erstellt und unterliegt ihren Größenbeschränkungen und Leistungseigenschaften.

Die ECDiffieHellman Klasse gibt den Wert "roh" der ECDH-Berechnung nicht zurück. Alle zurückgegebenen Daten sind in Bezug auf wichtige Ableitungsfunktionen:

  • HASH(Z)
  • HASH(vorab || Z || anfügen)
  • HMAC(key, Z)
  • HMAC(key, prepend || Z || anfügen)
  • HMAC(Z, Z)
  • HMAC(Z, vorab || Z || anfügen)
  • Tls11Prf(Label, Seed)

ECDH-Schlüsselkurven werden von den Betriebssystembibliotheken definiert und unterliegen ihren Einschränkungen.

Elliptische-Kurven- Windows 10 Windows 7 - 8.1 Linux macOS
NIST P-256 (secp256r1) ✔️ ✔️ ✔️ ✔️
NIST P-384 (secp384r1) ✔️ ✔️ ✔️ ✔️
NIST P-521 (secp521r1) ✔️ ✔️ ✔️ ✔️
Brainpoolkurven (wie benannte Kurven) ✔️ ⚠(1)
andere benannte Kurven ⚠^2 ⚠(1)
explizite Kurven ✔️ ✔️
Exportieren oder Importieren als explizit ✔️ 3 ✔️ 3

1 Linux-Verteilungen verfügen nicht über Unterstützung für dieselben benannten Kurven.

2 Unterstützung für benannte Kurven wurde Windows CNG in Windows 10 hinzugefügt. Weitere Informationen finden Sie unter CNG Named Elliptic Curves. Benannte Kurven sind in früheren Versionen von Windows nicht verfügbar, außer für drei Kurven in Windows 7.

3 Das Exportieren mit expliziten Kurvenparametern erfordert die Unterstützung der Betriebssystembibliothek, die auf macOS oder früheren Versionen von Windows nicht verfügbar ist.

ECDH-systemeigene Interop

.NET stellt Typen bereit, mit denen Programme mit den Betriebssystembibliotheken interoperiert werden können, die .NET verwendet. Die beteiligten Typen übersetzen nicht zwischen Plattformen und sollten nur bei Bedarf direkt verwendet werden.

type Windows Linux macOS
ECDiffieHellmanCng ✔️
ECDiffieHellmanOpenSsl ✔️ ⚠️*

* Funktioniert auf macOS, ECDiffieHellmanOpenSsl wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das laden der dynamischen Bibliothek gefunden werden kann. Wenn eine entsprechende Bibliothek nicht gefunden werden kann, werden Ausnahmen ausgelöst.

DSA

Die DSA (Digitale Signaturalgorithmus) wird von den Systembibliotheken durchgeführt und unterliegt ihren Größenbeschränkungen und Leistungseigenschaften.

Funktion Windows CNG Linux macOS Windows CAPI
Schlüsselerstellung (<= 1024 Bit) ✔️ ✔️ ✔️
Schlüsselerstellung (> 1024 Bit) ✔️ ✔️
Laden von Schlüsseln (<= 1024 Bit) ✔️ ✔️ ✔️ ✔️
Laden von Schlüsseln (> 1024 Bit) ✔️ ✔️ ⚠️*
FIPS 186-2 ✔️ ✔️ ✔️ ✔️
FIPS 186-3 (SHA-2 Signaturen) ✔️ ✔️

* macOS lädt DSA-Schlüssel größer als 1024 Bit, aber das Verhalten dieser Schlüssel ist nicht definiert. Sie verhalten sich nicht gemäß FIPS 186-3.

DSA auf Windows

  • Windows CryptoAPI (CAPI) wird immer verwendet, wenn new DSACryptoServiceProvider() sie verwendet wird.
  • Windows Kryptografie-API Next Generation (CNG) wird immer verwendet, wenn new DSACng() sie verwendet wird.
  • Das von Windows CNG zurückgegebene DSA.Create Objekt wird intern unterstützt. Diese Verwendung von Windows CNG ist ein Implementierungsdetails und unterliegt änderungen.
  • Die GetDSAPublicKey Erweiterungsmethode für X509Certificate2 die Rückgabe einer DSACng Instanz. Diese Verwendung DSACng ist ein Implementierungsdetails und unterliegt änderungen.
  • Die GetDSAPrivateKey Erweiterungsmethode für X509Certificate2 bevorzugt eine DSACng Instanz, aber wenn DSACng der Schlüssel nicht geöffnet werden kann, DSACryptoServiceProvider wird versucht. Der bevorzugte Anbieter ist ein Implementierungsdetails und unterliegt änderungen.

DSA-systemeigene Interop

.NET stellt Typen bereit, mit denen Programme mit den Betriebssystembibliotheken interoperiert werden können, die der .NET-Kryptografiecode verwendet. Die beteiligten Typen übersetzen nicht zwischen Plattformen und sollten nur bei Bedarf direkt verwendet werden.

type Windows Linux macOS
DSACryptoServiceProvider ✔️ ⚠(1) ⚠(1)
DSACng ✔️
DSAOpenSsl ✔️ ⚠^2

1 Unter macOS und Linux DSACryptoServiceProvider kann für die Kompatibilität mit vorhandenen Programmen verwendet werden. In diesem Fall löst jede Methode, die Systeminterop erfordert, z. B. das Öffnen eines benannten Schlüssels, eine PlatformNotSupportedException.

2 Auf macOS funktioniert es, DSAOpenSsl wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das laden der dynamischen Bibliothek gefunden werden kann. Wenn eine entsprechende Bibliothek nicht gefunden werden kann, werden Ausnahmen ausgelöst.

X.509-Zertifikate

Die Mehrheit der Unterstützung für X.509-Zertifikate in .NET stammt aus Betriebssystembibliotheken. Um ein Zertifikat in eine X509Certificate2X509Certificate Oder Instanz in .NET zu laden, muss das Zertifikat von der zugrunde liegenden Betriebssystembibliothek geladen werden.

Lesen einer PKCS12/PFX

Szenario Windows Linux macOS
Empty ✔️ ✔️ ✔️
Ein Zertifikat, kein privater Schlüssel ✔️ ✔️ ✔️
Ein Zertifikat mit privatem Schlüssel ✔️ ✔️ ✔️
Mehrere Zertifikate, keine privaten Schlüssel ✔️ ✔️ ✔️
Mehrere Zertifikate, ein privater Schlüssel ✔️ ✔️ ✔️
Mehrere Zertifikate, mehrere private Schlüssel ✔️ ⚠️* ✔️

* Verfügbar in .NET 5+.

Schreiben einer PKCS12/PFX

Szenario Windows Linux macOS
Empty ✔️ ✔️ ⚠️*
Ein Zertifikat, kein privater Schlüssel ✔️ ✔️ ⚠️*
Ein Zertifikat mit privatem Schlüssel ✔️ ✔️ ✔️
Mehrere Zertifikate, keine privaten Schlüssel ✔️ ✔️ ⚠️*
Mehrere Zertifikate, ein privater Schlüssel ✔️ ✔️ ✔️
Mehrere Zertifikate, mehrere private Schlüssel ✔️ ⚠️* ✔️
Ephemerales Laden ✔️ ✔️ ⚠️*

* Verfügbar in .NET 5+.

macOS kann keine privaten Zertifikatschlüssel ohne keychain-Objekt laden, was das Schreiben in den Datenträger erfordert. Keychains werden automatisch zum Laden von PFX erstellt und werden gelöscht, wenn sie nicht mehr verwendet werden. Da die X509KeyStorageFlags.EphemeralKeySet Option bedeutet, dass der private Schlüssel nicht auf den Datenträger geschrieben werden sollte, wird behauptet, dass das Flag auf macOS zu einer PlatformNotSupportedException.

Schreiben einer PKCS7-Zertifikatsammlung

Windows und Linux beide emittieren DER-codierte PKCS7-Blobs. macOS emittiert unbestimmte Länge-CER-codierte PKCS7-Blobs.

X509store

Auf Windows ist die X509Store Klasse eine Darstellung des Windows Zertifikats Store APIs. Diese APIs funktionieren in .NET Core und .NET 5 gleich wie in .NET Framework.

Bei Linux ist die X509Store Klasse eine Projektion von Systemvertrauenswürdigen Entscheidungen (schreibgeschützt), Benutzervertrauenswürdigkeitsentscheidungen (Lesezugriff) und Benutzerschlüsselspeicher (Lesezugriff).

Auf macOS ist die X509Store Klasse eine Projektion von Systemvertrauenswürdigen Entscheidungen (schreibgeschützt), Benutzervertrauenswürdigkeitsentscheidungen (schreibgeschützt) und Benutzerschlüsselspeicher (Schreibzugriff).

Die folgenden Tabellen zeigen, welche Szenarien in jeder Plattform unterstützt werden. Für nicht unterstützte Szenarien (❌ in den Tabellen) wird eine CryptographicException ausgelöst.

Mein Store

Szenario Windows Linux macOS
CurrentUser\My öffnen (ReadOnly) ✔️ ✔️ ✔️
CurrentUser\My öffnen (ReadWrite) ✔️ ✔️ ✔️
CurrentUser\My (ExistingOnly) öffnen ✔️ ⚠️ ✔️
LocalMachine\My öffnen ✔️ ✔️

Unter Linux werden Speicher beim ersten Schreiben erstellt, und standardmäßig sind keine Benutzerspeicher vorhanden, sodass das Öffnen CurrentUser\My mit ExistingOnly möglicherweise fehlschlägt.

Unter macOS ist der Speicher standardmäßig CurrentUser\My die Standardschlüsselkette login.keychain des Benutzers. Der LocalMachine\My Store ist System.keychain.

Der Stammspeicher

Szenario Windows Linux macOS
CurrentUser\Root öffnen (ReadOnly) ✔️ ✔️ ✔️
CurrentUser\Root öffnen (ReadWrite) ✔️ ✔️
CurrentUser\Root öffnen (ExistingOnly) ✔️ ⚠️ ✔️ (wenn ReadOnly)
Open LocalMachine\Root (ReadOnly) ✔️ ✔️ ✔️
Open LocalMachine\Root (ReadWrite) ✔️
Open LocalMachine\Root (ExistingOnly) ✔️ ⚠️ ✔️ (wenn ReadOnly)

Unter Linux ist der LocalMachine\Root Store eine Interpretation des CA-Bundles im Standardpfad für OpenSSL.

Unter macOS ist der CurrentUser\Root Store eine Interpretation der SecTrustSettings Ergebnisse für die Domäne des Benutzervertrauens. Der LocalMachine\Root Store ist eine Interpretation der SecTrustSettings Ergebnisse für die Domänen "Administrator" und "System trust".

Der Zwischenspeicher

Szenario Windows Linux macOS
Open CurrentUser\Intermediate (ReadOnly) ✔️ ✔️ ✔️
CurrentUser\Intermediate (ReadWrite) öffnen ✔️ ✔️
CurrentUser\Intermediate (ExistingOnly) öffnen ✔️ ⚠️ ✔️ (wenn ReadOnly)
Open LocalMachine\Intermediate (ReadOnly) ✔️ ✔️ ✔️
Open LocalMachine\Intermediate (ReadWrite) ✔️
Open LocalMachine\Intermediate (ExistingOnly) ✔️ ⚠️ ✔️ (wenn ReadOnly)

Unter Linux wird der CurrentUser\Intermediate Speicher als Cache verwendet, wenn zwischengespeicherte CAs von ihren Authority Information Access-Datensätzen auf erfolgreichen X509Chain-Builds heruntergeladen werden. Der LocalMachine\Intermediate Speicher ist eine Interpretation des CA-Bundles im Standardpfad für OpenSSL.

Der unzulässige Speicher

Szenario Windows Linux macOS
CurrentUser\Disallowed (ReadOnly) öffnen ✔️ ⚠️ ✔️
CurrentUser\Disallowed (ReadWrite) öffnen ✔️ ⚠️
CurrentUser\Disallowed (ExistingOnly) öffnen ✔️ ⚠️ ✔️ (wenn ReadOnly)
Open LocalMachine\Disallowed (ReadOnly) ✔️ ✔️
Open LocalMachine\Disallowed (ReadWrite) ✔️
Open LocalMachine\Disallowed (ExistingOnly) ✔️ ✔️ (wenn ReadOnly)

Unter Linux wird der Disallowed Speicher nicht im Kettenbau verwendet, und der Versuch, Inhalte hinzuzufügen, führt zu einem CryptographicException. Beim Öffnen des Disallowed Speichers wird ein CryptographicException Fehler ausgelöst, wenn er bereits Inhalte erworben hat.

Unter macOS sind die CurrentUser\Disallowed- und LocalMachine\Disallowed-Speicher Interpretationen der entsprechenden SecTrustSettings-Ergebnisse für Zertifikate, deren Vertrauensstellung auf Always Denyfestgelegt ist.

Nicht vorhandener Speicher

Szenario Windows Linux macOS
Nicht vorhandene Speicher öffnen (ExistingOnly)
Open CurrentUser non-existent store (ReadWrite) ✔️ ✔️ ⚠️
Open LocalMachine non-existent store (ReadWrite) ✔️

Unter macOS wird die benutzerdefinierte Storeerstellung mit der X509Store-API nur für CurrentUser den Speicherort unterstützt. Er erstellt eine neue Schlüsselkette ohne Kennwort im Schlüsselbundverzeichnis des Benutzers (~/Library/Keychains). Um eine Schlüsselkette mit Kennwort zu SecKeychainCreate erstellen, könnte ein P/Invoke verwendet werden. Ebenso könnte es verwendet werden, SecKeychainOpen um Schlüsselketten an verschiedenen Stellen zu öffnen. Die resultierenden IntPtr Elemente können übergeben werden, um new X509Store(IntPtr) einen lese-/schreibfähigen Speicher zu erhalten, der den Berechtigungen des aktuellen Benutzers unterliegt.

X509chain

macOS unterstützt keine Offline-CRL-Auslastung, wird also X509RevocationMode.Offline als X509RevocationMode.Onlinebehandelt.

macOS unterstützt kein vom Benutzer initiiertes Timeout auf CRL (Zertifikatsperrliste) / OCSP (Online Certificate Status Protocol) / AIA (Authority Information Access) herunterladen, daher X509ChainPolicy.UrlRetrievalTimeout wird ignoriert.

Zusätzliche Ressourcen