Plattformübergreifend Kryptografie in .NET

Artikel
10/15/2024

Kryptografische Vorgänge in .NET werden von Betriebssystembibliotheken durchgeführt. Diese Abhängigkeit hat Vorteile:

.NET-Apps profitieren von der Zuverlässigkeit des Betriebssystems. Kryptografiebibliotheken vor Sicherheitsrisiken zu schützen, hat für Betriebssystemhersteller eine hohe Priorität. Dazu stellen sie Updates bereit, die Systemadministratoren anwenden sollten.
.NET-Apps haben Zugriff auf FIPS-validierte Algorithmen, wenn die Betriebssystembibliotheken FIPS-validiert sind.

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

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

Hash- und MAC-Algorithmen (Message Authentication)

Alle Hash-Algorithmus- und HMAC-Klassen (Hash-Based Message Authentication), einschließlich der *Managed-Klassen, verweisen auf die Betriebssystembibliotheken. Die einzige Ausnahme ist .NET in Browser WASM. In Browser WASM werden SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 und deren HMAC-Äquivalente mithilfe von verwaltetem Code implementiert.

Algorithmus	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android	Browser
MD5	✔️	✔️	✔️	✔️	✔️	❌
SHA-1	✔️	✔️	✔️	✔️	✔️	✔️
SHA-2-256	✔️	✔️	✔️	✔️	✔️	✔️
SHA-2-384	✔️	✔️	✔️	✔️	✔️	✔️
SHA-2-512	✔️	✔️	✔️	✔️	✔️	✔️
SHA-3-256¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
SHA-3-384¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
SHA-3-512¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
SHAKE-128¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1+³	❌	❌	❌	❌
SHAKE-256¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1+³	❌	❌	❌	❌
HMAC-MD5	✔️	✔️	✔️	✔️	✔️	❌
HMAC-SHA-1	✔️	✔️	✔️	✔️	✔️	✔️
HMAC-SHA-2-256	✔️	✔️	✔️	✔️	✔️	✔️
HMAC-SHA-2-384	✔️	✔️	✔️	✔️	✔️	✔️
HMAC-SHA-2-512	✔️	✔️	✔️	✔️	✔️	✔️
HMAC-SHA-3-256¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
HMAC-SHA-3-384¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
HMAC-SHA-3-512¹	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
KMAC-128²	Windows 11 Build 26016 und höher	OpenSSL 3.0+	❌	❌	❌	❌
KMAC-256²	Windows 11 Build 26016 und höher	OpenSSL 3.0+	❌	❌	❌	❌
KMAC-XOF-128²	Windows 11 Build 26016 und höher	OpenSSL 3.0+	❌	❌	❌	❌
KMAC-XOF-256²	Windows 11 Build 26016 und höher	OpenSSL 3.0+	❌	❌	❌	❌

¹Verfügbar ab .NET 8.

²Verfügbar ab .NET 9.

³Die erweiterbare Streamingausgabefunktion (XOF) ist ab .NET 9 verfügbar. Unter Linux erfordert dies OpenSSL 3.3.

Symmetrische Verschlüsselung

Die zugrunde liegenden Verschlüsselungsverfahren und Verkettungen werden von den Systembibliotheken durchgeführt.

Verschlüsselung + Modus	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
AES-CBC	✔️	✔️	✔️	✔️	✔️
AES-ECB	✔️	✔️	✔️	✔️	✔️
AES-CFB8	✔️	✔️	✔️	✔️	✔️
AES-CFB128	✔️	✔️	✔️	✔️	✔️
3DES-CBC	✔️	✔️	✔️	✔️	✔️
3DES-ECB	✔️	✔️	✔️	✔️	✔️
3DES-CFB8	✔️	✔️	✔️	✔️	✔️
3DES-CFB64	✔️	✔️	✔️	✔️	✔️
DES-CBC	✔️	✔️	✔️	✔️	✔️
DES-ECB	✔️	✔️	✔️	✔️	✔️
DES-CFB8	✔️	✔️	✔️	✔️	✔️
RC2-CBC	✔️	✔️	✔️	✔️	❌
RC2-ECB	✔️	✔️	✔️	✔️	❌
RC2-CFB	❌	❌	❌	❌	❌

Authentifizierte Verschlüsselung

Die Unterstützung der authentifizierten Verschlüsselung (AE) wird für AES-CCM, AES-GCM und ChaCha20Poly1305 jeweils über die Klassen System.Security.Cryptography.AesCcm, System.Security.Cryptography.AesGcm und System.Security.Cryptography.ChaCha20Poly1305 bereitgestellt.

Da für die authentifizierte Verschlüsselung neuere Plattform-APIs erforderlich sind, um den Algorithmus zu unterstützen, ist die Unterstützung möglicherweise nicht auf allen Plattformen verfügbar. Die statische Eigenschaft IsSupported der Klassen für den Algorithmus kann zur Laufzeit verwendet werden, um zu erkennen, ob die aktuelle Plattform den Algorithmus unterstützt oder nicht.

Verschlüsselung + Modus	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android	Browser
AES-GCM	✔️	✔️	⚠️	⚠️	✔️	❌
AES-CCM	✔️	✔️	⚠️	❌	✔️	❌
ChaCha20Poly1305	Windows 10 Build 20142 und höher	OpenSSL 1.1.0 und höher	⚠️	⚠️	API-Ebene 28 und höher	❌

AES-CCM unter macOS

Unter macOS unterstützen die Systembibliotheken AES-CCM für Code von Drittanbietern nicht, daher verwendet die Klasse AesCcm OpenSSL zur Unterstützung. macOS-Benutzer*innen müssen eine geeignete Kopie von OpenSSL (libcrypto) abrufen, damit dieser Typ funktioniert, und dieser muss sich unter einem Pfad befinden, aus dem das System standardmäßig eine Bibliothek laden würde. Es wird empfohlen, OpenSSL über einen Paket-Manager wie Homebrew zu installieren.

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

AES-GCM und ChaCha20Poly1305 unter macOS

macOS hat AES-GCM oder ChaCha20Poly1305 bis macOS 10.15 für Drittanbietercode nicht unterstützt. Vor .NET 8 haben AesGcm und ChaCha20Poly1305 die gleiche Anforderung wie AES-CCM, und Benutzer*innen müssen OpenSSL installieren, damit diese Typen funktionieren.

Ab .NET 8 verwendet .NET unter macOS das CryptoKit-Framework von Apple für AES-GCM und ChaCha20Poly1305. Benutzer*innen müssen keine zusätzlichen Abhängigkeiten für AES-GCM oder ChaCha20Poly1305 unter macOS installieren oder konfigurieren.

AES-GCM und ChaCha20Poly1305 unter iOS, tvOS und MacCatalyst

Die Unterstützung für AES-GCM und ChaCha20Poly1305 steht ab .NET 9 unter iOS und tvOS 13.0 und höher sowie in allen Versionen von MacCatalyst zur Verfügung.

AES-CCM-Schlüssel, Nonces und Tags

Schlüsselgrößen

AES-CCM kann mit 128-, 192- und 256-Bit-Schlüsseln verwendet werden.
Nonce-Größen

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

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

AES-GCM-Schlüssel, Nonces und Tags

Schlüsselgrößen

AES-GCM kann mit 128-, 192- und 256-Bit-Schlüsseln verwendet werden.
Nonce-Größen

Die Klasse AesGcm unterstützt nur Nonces mit 96 Bit (12 Byte).
Taggrößen unter Windows und Linux: Die Klasse AesGcm unterstützt das Erstellen oder Verarbeiten von Tags mit 96, 104, 112, 120 und 128 Bit (12, 13, 14, 15 und 16 Byte). Auf Apple-Plattformen ist die Tag-Größe aufgrund von Einschränkungen des CryptoKit-Frameworks auf 128 Bit (16 Byte) begrenzt.

ChaCha20Poly1305-Schlüssel, -Nonces und -Tags

ChaCha20Poly1305 hat eine feste Größe für das Schlüssel-, Nonce- und Authentifizierungstag. ChaCha20Poly1305 verwendet immer einen 256-Bit-Schlüssel, eine 96-Bit-Nonce (12 Byte)- und ein 128-Bit-Tag (16 Byte).

Asymmetrische Kryptografie

Dieser Abschnitt enthält die folgenden Unterabschnitte:

RSA
ECDSA
ECDH
DSA

RSA

Die RSA-Schlüsselgenerierung (Rivest–Shamir–Adleman) wird von den Betriebssystembibliotheken durchgeführt und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

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 macht keine "rohen" (ungespeicherten) RSA-Vorgänge verfügbar.

Die Unterstützung für Abstand und Digest variiert je nach Plattform:

Ein Paddingmodus	Windows (CNG)	Linux (OpenSSL)	macOS	iOS, tvOS, MacCatalyst	Android	Windows (CAPI)
PKCS1-Verschlüsselung	✔️	✔️	✔️	✔️	✔️	✔️
OAEP – SHA-1	✔️	✔️	✔️	✔️	✔️	✔️
OAEP: SHA-2	✔️	✔️	✔️	✔️	✔️	❌
OAEP: SHA-3²	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
PKCS1-Signatur (MD5, SHA-1)	✔️	✔️	✔️	✔️	✔️	✔️
PKCS1-Signatur (SHA-2)	✔️	✔️	✔️	✔️	✔️	⚠️¹
PKCS1-Signatur (SHA-3)²	Windows 11 Build 25324 und höher	OpenSSL 1.1.1 und höher	❌	❌	❌	❌
PSS	✔️	✔️	✔️	✔️	✔️	❌

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

² Erfordert .NET 8

RSA unter Windows

Windows CryptoAPI (CAPI) wird immer verwendet, wenn new RSACryptoServiceProvider() verwendet wird.
Windows Cryptography API Next Generation (CNG) wird immer verwendet, wenn new RSACng() verwendet wird.
Das von RSA.Create zurückgegebene Objekt wird intern von Windows CNG unterstützt. Diese Verwendung von Windows CNG ist ein Implementierungsdetail und kann geändert werden.
Die GetRSAPublicKey-Erweiterungsmethode für X509Certificate2 gibt eine RSACng-Instanz zurück. Diese Verwendung von RSACng ist ein Implementierungsdetail und kann geändert werden.
Die GetRSAPrivateKey-Erweiterungsmethode für X509Certificate2 bevorzugt derzeit eine RSACng-Instanz, aber wenn RSACng den Schlüssel nicht öffnen kann, wird es mit RSACryptoServiceProvider versucht. Der bevorzugte Anbieter ist ein Implementierungsdetail und kann geändert werden.

RSA-natives Interop

.NET macht Typen verfügbar, damit Programme mit den Betriebssystembibliotheken zusammenarbeiten können, die vom .NET-Kryptografiecode verwendet werden. Die beteiligten Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf direkt verwendet werden.

type	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
RSACryptoServiceProvider	✔️	⚠️¹	⚠️¹	⚠️¹	⚠️¹
RSACng	✔️	❌	❌	❌	❌
RSAOpenSsl	❌	✔️	⚠️²	❌	❌

¹ Unter anderen Betriebssystemen als Windows kann RSACryptoServiceProvider zur Kompatibilität mit vorhandenen Programmen verwendet werden. In diesem Fall löst jede Methode, die Betriebssystem-Interop erfordert, z. B. das Öffnen eines benannten Schlüssels, eine PlatformNotSupportedException aus.

² Unter macOS kann RSAOpenSsl verwendet werden, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.

ECDSA

Die ECDSA-Schlüsselgenerierung (Elliptic Curve Digital Signature Algorithm) erfolgt durch die Betriebssystembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

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

Elliptische-Kurven-	Windows 10	Windows 7–8.1	Linux	macOS	iOS, tvOS, MacCatalyst	Android
NIST P-256 (secp256r1)	✔️	✔️	✔️	✔️	✔️	✔️
NIST P-384 (secp384r1)	✔️	✔️	✔️	✔️	✔️	✔️
NIST P-521 (secp521r1)	✔️	✔️	✔️	✔️	✔️	✔️
Brainpoolkurven (als benannte Kurven)	✔️	❌	⚠️¹	❌	❌	⚠️⁴
Andere benannte Kurven	⚠️²	❌	⚠️¹	❌	❌	⚠️⁴
Explizite Kurven	✔️	❌	✔️	❌	❌	✔️
Exportieren oder Importieren als „explizit“	✔️	❌³	✔️	❌³	❌³	✔️

¹ Nicht alle Linux-Verteilungen unterstützen die gleichen benannten Kurven.

² Unterstützung für benannte Kurven wurde Windows CNG in Windows 10 hinzugefügt. Weitere Informationen finden Sie unter Benannte elliptische Kurven in CNG. Benannte Kurven sind in früheren Versionen von Windows nicht verfügbar, mit Ausnahme von drei Kurven in Windows 7.

³ Für den Export mit expliziten Kurvenparametern ist die Unterstützung der Betriebssystembibliothek erforderlich, die unter Apple-Plattformen oder früheren Versionen von Windows nicht verfügbar ist.

⁴ Die Android-Unterstützung für einige Kurven hängt von der Android-Version ab. Android-Vertriebspartner können auch Kurven aus ihrem Android-Build hinzufügen oder entfernen.

ECDSA-natives Interop

.NET macht Typen verfügbar, damit Programme mit den Betriebssystembibliotheken zusammenarbeiten können, die vom .NET-Kryptografiecode verwendet werden. Die betroffenen Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf und direkt verwendet werden.

type	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
ECDsaCng	✔️	❌	❌	❌	❌
ECDsaOpenSsl	❌	✔️	⚠️*	❌	❌

* Unter macOS kann ECDsaOpenSsl verwendet werden, wenn OpenSSL im System installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.

ECDH

Die ECDH-Schlüsselgenerierung (Elliptic Curve Diffie-Hellman) erfolgt durch die Betriebssystembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

Die ECDiffieHellman-Klasse unterstützt den Rohwert der ECDH-Berechnung sowie durch die folgenden Schlüsselableitungsfunktionen:

HASH(Z)
HASH(prepend || Z || append)
HMAC(key, Z)
HMAC(key, prepend || Z || append)
HMAC(Z, Z)
HMAC(Z, prepend || Z || append)
Tls11Prf(label, seed)

Die Ableitung des Rohschlüssels wurde in .NET 8 eingeführt.

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

Elliptische-Kurven-	Windows 10	Windows 7–8.1	Linux	macOS	iOS, tvOS, MacCatalyst	Android
NIST P-256 (secp256r1)	✔️	✔️	✔️	✔️	✔️	✔️
NIST P-384 (secp384r1)	✔️	✔️	✔️	✔️	✔️	✔️
NIST P-521 (secp521r1)	✔️	✔️	✔️	✔️	✔️	✔️
Brainpoolkurven (als benannte Kurven)	✔️	❌	⚠️¹	❌	❌	⚠️⁴
Andere benannte Kurven	⚠️²	❌	⚠️¹	❌	❌	⚠️⁴
Explizite Kurven	✔️	❌	✔️	❌	❌	✔️
Exportieren oder Importieren als „explizit“	✔️	❌³	✔️	❌³	❌³	✔️

¹ Nicht alle Linux-Verteilungen unterstützen die gleichen benannten Kurven.

⁴ Die Android-Unterstützung für einige Kurven hängt von der Android-Version ab. Android-Vertriebspartner können auch Kurven aus ihrem Android-Build hinzufügen oder entfernen.

ECDH-natives Interop

.NET macht Typen verfügbar, damit Programme mit den von .NET verwendeten Betriebssystembibliotheken zusammenarbeiten können. Die betroffenen Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf und direkt verwendet werden.

type	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
ECDiffieHellmanCng	✔️	❌	❌	❌	❌
ECDiffieHellmanOpenSsl	❌	✔️	⚠️*	❌	❌

* Unter macOS kann ECDiffieHellmanOpenSsl verwendet werden, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.

DSA

Die DSA-Schlüsselgenerierung (Digital Signature Algorithm) erfolgt durch die Systembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

Funktion	Windows CNG	Linux	macOS	Windows CAPI	iOS, tvOS, MacCatalyst	Android
Schlüsselerstellung (< = 1024 Bits)	✔️	✔️	❌	✔️	❌	✔️
Schlüsselerstellung (> 1024 Bits)	✔️	✔️	❌	❌	❌	✔️
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, die größer als 1024 Bit sind, aber das Verhalten dieser Schlüssel ist nicht definiert. Sie verhalten sich nicht gemäß FIPS 186-3.

DSA unter Windows

Windows CryptoAPI (CAPI) wird immer verwendet, wenn new DSACryptoServiceProvider() verwendet wird.
Windows Cryptography API Next Generation (CNG) wird immer verwendet, wenn new DSACng() verwendet wird.
Das von DSA.Create zurückgegebene Objekt wird intern von Windows CNG unterstützt. Diese Verwendung von Windows CNG ist ein Implementierungsdetail und kann geändert werden.
Die GetDSAPublicKey-Erweiterungsmethode für X509Certificate2 gibt eine DSACng-Instanz zurück. Diese Verwendung von DSACng ist ein Implementierungsdetail und kann geändert werden.
Die GetDSAPrivateKey-Erweiterungsmethode für X509Certificate2 bevorzugt eine DSACng-Instanz, aber wenn DSACng den Schlüssel nicht öffnen kann, wird es mit DSACryptoServiceProvider versucht. Der bevorzugte Anbieter ist ein Implementierungsdetail und kann geändert werden.

DSA-natives Interop

type	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
DSACryptoServiceProvider	✔️	⚠️¹	⚠️¹	❌	⚠️¹
DSACng	✔️	❌	❌	❌	❌
DSAOpenSsl	❌	✔️	⚠️²	❌	❌

¹ Unter anderen Betriebssystemen als Windows kann DSACryptoServiceProvider zur Kompatibilität mit vorhandenen Programmen verwendet werden. In diesem Fall löst jede Methode, die System-Interop erfordert, z. B. das Öffnen eines benannten Schlüssels, eine PlatformNotSupportedException aus.

² Unter macOS kann DSAOpenSsl verwendet werden, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.

X.509-Zertifikate

Der Großteil der Unterstützung für X.509-Zertifikate in .NET stammt von Betriebssystembibliotheken. Um ein Zertifikat in eine X509Certificate2- oder X509Certificate-Instanz in .NET zu laden, muss das Zertifikat von der zugrunde liegenden Betriebssystembibliothek geladen werden.

Lesen eines PKCS12/PFX

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Leer	✔️	✔️	✔️	✔️	✔️
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	✔️	✔️	✔️	✔️	✔️

Schreiben eines PKCS12/PFX

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Leer	✔️	✔️	✔️	✔️	✔️
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	✔️	✔️	✔️	✔️	✔️
Kurzlebiges Laden	✔️	✔️	❌	✔️	✔️

macOS kann keine privaten Zertifikatschlüssel ohne ein Schlüsselbundobjekt laden, das Schreiben auf den Datenträger erfordert. Schlüsselbunde werden automatisch für das PFX-Laden erstellt und gelöscht, wenn sie nicht mehr verwendet werden. Da die Option X509KeyStorageFlags.EphemeralKeySet bedeutet, dass der private Schlüssel nicht auf den Datenträger geschrieben werden soll, führt die Angabe dieses Flags unter macOS zu einem PlatformNotSupportedException.

Schreiben einer PKCS7-Zertifikatsammlung

Sowohl Windows als auch Linux geben DER-codierte PKCS7-Blobs aus. macOS gibt CER-codierte PKCS7-Blobs mit undefinierter Länge aus.

X509Store

Unter Windows ist die Klasse X509Store eine Darstellung der Windows-Zertifikatspeicher-APIs. Diese APIs funktionieren in .NET Core und .NET 5 genauso wie in .NET Framework.

Unter anderen Betriebssystemen als Windows ist die Klasse X509Store eine Projektion der Systemvertrauensentscheidungen (schreibgeschützt), Benutzervertrauensentscheidungen (Lese-/Schreibzugriff) und Benutzerschlüsselspeicher (Lese-/Schreibzugriff).

Die folgenden Tabellen zeigen, welche Szenarien auf den einzelnen Plattformen unterstützt werden. Bei nicht unterstützten Szenarien (❌ in den Tabellen) wird eine CryptographicException ausgelöst.

Mein Speicher

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Öffnen von CurrentUser\My (ReadOnly)	✔️	✔️	✔️	✔️	✔️
Öffnen von CurrentUser\My (ReadWrite)	✔️	✔️	✔️	✔️	✔️
Öffnen von CurrentUser\My (ExistingOnly)	✔️	⚠️	✔️	✔️	✔️
Öffnen von LocalMachine\My	✔️	❌	✔️	✔️	✔️

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

Unter macOS ist der Standardschlüsselbund des Benutzers der CurrentUser\My-Speicher, standardmäßig also login.keychain. Der LocalMachine\My-Speicher ist System.keychain.

Stammspeicher

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Öffnen von CurrentUser\Root (ReadOnly)	✔️	✔️	✔️	❌	✔️
Öffnen von CurrentUser\Root (ReadWrite)	✔️	✔️	❌	❌	❌
Öffnen von CurrentUser\Root (ExistingOnly)	✔️	⚠️	✔️ (wenn ReadOnly)	❌	✔️ (wenn ReadOnly)
Öffnen von LocalMachine\Root (ReadOnly)	✔️	✔️	✔️	❌	✔️
Öffnen von LocalMachine\Root (ReadWrite)	✔️	❌	❌	❌	❌
Öffnen von LocalMachine\Root (ExistingOnly)	✔️	⚠️	✔️ (wenn ReadOnly)	❌	✔️ (wenn ReadOnly)

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

Unter macOS ist der CurrentUser\Root-Speicher eine Interpretation der SecTrustSettings-Ergebnisse für die Domäne der Benutzervertrauensstellung. Der LocalMachine\Root-Speicher ist eine Interpretation der SecTrustSettings-Ergebnisse für die Domänen der Administrator- und Systemvertrauensstellung.

Zwischenspeicher

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Öffnen von CurrentUser\Intermediate (ReadOnly)	✔️	✔️	✔️	❌	❌
Öffnen von CurrentUser\Intermediate (ReadWrite)	✔️	✔️	❌	❌	❌
Öffnen von CurrentUser\Intermediate (ExistingOnly)	✔️	⚠️	✔️ (wenn ReadOnly)	❌	❌
Öffnen von LocalMachine\Intermediate (ReadOnly)	✔️	✔️	✔️	❌	❌
Öffnen von LocalMachine\Intermediate (ReadWrite)	✔️	❌	❌	❌	❌
Öffnen von LocalMachine\Intermediate (ExistingOnly)	✔️	⚠️	✔️ (wenn ReadOnly)	❌	❌

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

Unter macOS wird der CurrentUser\Intermediate-Speicher als benutzerdefinierter Speicher behandelt. Zertifikate, die diesem Speicher hinzugefügt wurden, wirken sich nicht auf das Erstellen von X.509-Ketten aus.

Unzulässiger Speicher

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Öffnen von CurrentUser\Disallowed (ReadOnly)	✔️	⚠️	✔️	✔️	✔️
Öffnen von CurrentUser\Disallowed (ReadWrite)	✔️	⚠️	❌	❌	❌
Öffnen von CurrentUser\Disallowed (ExistingOnly)	✔️	⚠️	✔️ (wenn ReadOnly)	✔️ (wenn ReadOnly)	✔️ (wenn ReadOnly)
Öffnen von LocalMachine\Disallowed (ReadOnly)	✔️	❌	✔️	✔️	✔️
Öffnen von LocalMachine\Disallowed (ReadWrite)	✔️	❌	❌	❌	❌
Öffnen von LocalMachine\Disallowed (ExistingOnly)	✔️	❌	✔️ (wenn ReadOnly)	✔️ (wenn ReadOnly)	✔️ (wenn ReadOnly)

Unter Linux wird der Disallowed-Speicher beim Erstellen von Ketten nicht verwendet, und der Versuch, Inhalte hinzuzufügen, führt zu einer CryptographicException. Eine CryptographicException wird beim Öffnen des Disallowed-Speichers ausgelöst, wenn er bereits Inhalte erworben hat.

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

Nicht vorhandener Speicher

Szenario	Windows	Linux	macOS	iOS, tvOS, MacCatalyst	Android
Öffnen eines nicht vorhandenen Speichers (ExistingOnly)	❌	❌	❌	❌	❌
Öffnen eines nicht vorhandenen CurrentUser-Speichers (ReadWrite)	✔️	✔️	⚠️	❌	❌
Öffnen eines nicht vorhandenen LocalMachine-Speichers (ReadWrite)	✔️	❌	❌	❌	❌

Unter macOS wird die Erstellung eines benutzerdefinierten Speichers mit der X509Store-API nur für den Standort CurrentUser unterstützt. Es wird ein neues Schlüsselbund ohne Kennwort im Schlüsselbundverzeichnis des Benutzers erstellt (~/Library/Keychains). Um ein Schlüsselbund mit Kennwort zu erstellen, kann ein „P/Invoke“ zu SecKeychainCreate verwendet werden. Auf ähnliche Weise kann SecKeychainOpen verwendet werden, um Schlüsselbunde an verschiedenen Standorten zu öffnen. Der resultierende IntPtr kann an new X509Store(IntPtr) übergeben werden, um einen lese-/schreibfähigen Speicher zu erhalten, abhängig von den Berechtigungen des aktuellen Benutzers.

X509Chain

macOS unterstützt keine Offline-CRL-Nutzung, daher X509RevocationMode.Offline wird als X509RevocationMode.Online behandelt.

macOS unterstützt kein vom Benutzer initiiertes Timeout für das Herunterladen von Zertifikatsperrlisten (Certificate Revocation List) / OCSP (Online Certificate Status Protocol) / AIA (Authority Information Access) und daher wird X509ChainPolicy.UrlRetrievalTimeout ignoriert.

Freigeben über