Stellt man S/MIME Zertifikate aus, beinhalten diese üblicherweise eine Zertifikaterweiterung "S/MIME Capabilities". Diese Zertifikaterweiterung ist in RFC 4262 spezifiziert und kann von kompatiblen E-Mail Programmen dazu verwendet werden, die vom Empfänger einer verschlüsselten Nachricht unterstützten symmetrischen Algorithmen zu spezifizieren. Der Absender sollte dann den jeweils stärksten vom Empfänger unterstützen Algorithmus wählen.
Wirft man einen Blick auf die in einem solchen Zertifikat enthaltenen symmetrischen Algorithmen, wird man jedoch vermutlich feststellen, dass die Liste eher veraltete Algorithmen enthält – der "stärkste" dieser Algorithmen ist der mittlerweile als übrholt geltende Triple-DES (3DES).
Wie kommen die Algorithmen ins Zertifikat?
Wichtig hierbei ist, zu verstehen, dass die im Zertifikat eingetragenen Werte von der Art der Beantragung abhängen:
- Beinhaltet die Zertifikatanforderung keine "S/MIME Capabilities" Erweiterung, werden die Standardwerte aus dem Registrierungsschlüssel "DefaultSMIME" der Zertifizierungsstelle verwendet und in das ausgestellte Zertifikat geschrieben.
- Beinhaltet die Zertifikatanforderung eine "S/MIME Capabilities" Erweiterung, werden die beantragten Werte 1:1 in das ausgestellte Zertifikat übernommen.
Wird die Beantragung über die Windows-Mittel (Microsoft Management Console oder AutoEnrollment) erzeugt, werden folgende Werte in die Zertifikatanforderung geschrieben:
Standardwerte für eine Zertifikatvorlage mit einem Cryptographic Service Provider (CSP)
Ist in der Zertifikatvorlage ein Cryptographic Service Provider konfiguriert, werden immer folgende Werte beantragt:
[1]SMIME Capability Object ID=1.2.840.113549.3.2 Parameters=02 02 00 80 [2]SMIME Capability Object ID=1.2.840.113549.3.4 Parameters=02 02 00 80 [3]SMIME Capability Object ID=1.3.14.3.2.7 [4]SMIME Capability Object ID=1.2.840.113549.3.7
Dies entspricht folgenden Algorithmen:
- RC2 im CBC-Modus mit 128-Bit Schlüssellänge
- RC4 mit 128-Bit Schlüssellänge
- DES mit 56-Bit Schlüssellänge
- 3DES mit 168-Bit Schlüssellänge
Standardwerte für eine Zertifikatvorlage mit einem Key Storage Provider (KSP)
Wichtig hierbei zu verstehen ist, dass der Umstand, dass die modernen Algorithmen nur dann im Zertifikat auftauchen, wenn ein Key Storage Provider verwendet wird, keine technische Voraussetzung sind. Die modernen symmerischen Algorithmen können – rein technisch betrachtet – auch mit einem Zertifikat genutzt werden, welches auf einem Cryptographic Service Provider basiert, wenn die Zertifikatanforderung die entsprechenden Erweiterungen aufweist.
Ist in der Zertifikatvorlage ein Key Storage Provider konfiguriert, werden immer folgende Werte beantragt:
[1]SMIME Capability Object ID=2.16.840.1.101.3.4.1.42 [2]SMIME Capability Object ID=2.16.840.1.101.3.4.1.45 [3]SMIME Capability Object ID=2.16.840.1.101.3.4.1.22 [4]SMIME Capability Object ID=2.16.840.1.101.3.4.1.25 [5]SMIME Capability Object ID=2.16.840.1.101.3.4.1.2 [6]SMIME Capability Object ID=2.16.840.1.101.3.4.1.5 [7]SMIME Capability Object ID=1.2.840.113549.3.7 [8]SMIME Capability Object ID=1.3.14.3.2.7 [9]SMIME Capability Object ID=1.2.840.113549.3.2 Parameters=02 02 00 80 [10]SMIME Capability Object ID=1.2.840.113549.3.4 Parameters=02 02 02 00
Dies entspricht folgenden Algorithmen:
- RC2 im CBC-Modus mit 128-Bit Schlüssellänge
- RC4 mit 128-Bit Schlüssellänge
- DES mit 56-Bit Schlüssellänge
- 3DES mit 168-Bit Schlüssellänge
- AES im CBC-Modus mit 128-Bit Schlüssellänge
- AES im CBC-Modus mit 192-Bit Schlüssellänge
- AES im CBC-Modus mit 256-Bit Schlüssellänge
- AES im Key Wrapping-Modus mit 128-Bit Schlüssellänge
- AES im Key Wrapping-Modus mit 192-Bit Schlüssellänge
- AES im Key Wrapping-Modus mit 256-Bit Schlüssellänge
Standardwerte synchron halten mit den Zertifikatvorlagen
In der Regel werden die Werte in der Registrierung der Zertifizierungsstelle also gar nicht verwendet. Nur für den Fall, dass eine Zertifikatanforderung ohne die "S/MIME Capabilities" Erweiterung eingericht wird, wird auf die hier konfigurierten Standardwerte zurückgegriffen:
HKLM:\SYSTEM\CurrentControlSet\Service\CertSvc\Configuration\{Name-der-Zertifizierungsstelle}\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\DefaultSMIME
Um die unter DefaultSMIME eingetragenen Standardwerte synchron zu halten mit dem, was durch eine auf einen Key Storage Provider konfigurierte Zertifikatvorlage beantragt wird, müssten auf der Zertifizierungsstelle zusätzlich zur Standardeinstellung noch folgende Werte konfiguriert werden:
certutil -setreg policy\defaultsmime +2.16.840.1.101.3.4.1.42 certutil -setreg policy\defaultsmime +2.16.840.1.101.3.4.1.45 certutil -setreg policy\defaultsmime +2.16.840.1.101.3.4.1.22 certutil -setreg policy\defaultsmime +2.16.840.1.101.3.4.1.25 certutil -setreg policy\defaultsmime +2.16.840.1.101.3.4.1.2 certutil -setreg policy\defaultsmime +2.16.840.1.101.3.4.1.5
Der Zertifizierungsstellen-Dienst muss anschließend neu gestartet werden, damit die Änderungen angewendet werden.
S/MIME Capabilities feingranular steuern
Möchte man erreichen, dass Zertifikate nur bestimmte S/MIME Capabilities enthalten, so ist dies nur über angepasste Zertifikatanforderungen möglich, jedoch nicht über die vorhandenen Bordmittel, da diese immer Standardwerte eintragen.
Der Denkfehler hierbei ist, dass wir als Betreiber PKI lediglich die Wünsche der Antragsteller in die ausgestellten Zertifikate eintragen. Welche Möglichkeiten das E-Mail Programms der Antragsteller jedoch tatsächlich unterstützt, liegt logischerweise auch in dessen Hand.
Manuelle Beantragung eines S/MIME Zertifikats
Eine manuelle Erstellung einer Zertifikatanforderung für ein S/MIME Zertifikat kann beispielsweise über das PSCertificateEnrollment PowerShell Modul erfolgen.
Beispiel:
New-CertificateRequest ` -Exportable ` -Subject "CN=Testuser,E=testuser@adcslabor.de" ` -Email "testuser@adcslabor.de" ` -EnhancedKeyUsage SecureEmail ` -KeyUsage DigitalSignature,KeyEncipherment ` -SmimeCapabilities aes128,aes192,aes256,sha256,sha384,sha512
Bitte beachten, dass bei einer solchen Beantragung keine zentrale Archivierung des privaten Schlüssels möglich ist. Der Antragsteller ist für die Sicherung seines privaten Schlüssels selbst verantwortlich. Der private Schlüssel sollte daher bei der Beantragung als exportierbar markiert und gesichert werden.
Weiterführende Links:
Externe Quellen:
- X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities (Internet Engineering Task Force)
Deutsch 
English
2 Gedanken zu „Die "S/MIME Capabilities" Zertifikaterweiterung in ausgestellten Zertifikaten um die Cryptography Next Generation (CNG) Algorithmen erweitern“
Kommentare sind geschlossen.