Erweiterungshandler

Ab Version 3 des X.509-Zertifikatformats kann ein Zertifikat Zertifikaterweiterungen enthalten. (Den Inhalt eines X.509-Zertifikats finden Sie unter Zertifikateigenschaften.) Diese Erweiterungen geben zusätzliche Informationen an. Beispielsweise kann eine Erweiterung zusätzliche Informationen zur Personenidentifikation angeben, oder sie kann wichtige Nutzungsinformationen angeben, die die Aufgaben (z. B. Signatur oder Verschlüsselung) angeben, für die ein Schlüssel verwendet werden kann. Eine Reihe von Standarderweiterungen ist für die Anwendungsverwendung definiert, und Erweiterungen können auch angepasst werden.

Jede Erweiterung verfügt über eine zugeordnete Objektbezeichnerzeichenfolge, die den Typ der zusätzlichen Informationen identifiziert, und eine Datenstruktur, die diese Informationen enthält. Der Schlüsselverwendungsobjektbezeichner lautet z. B. "2.5.29.15", was informationen zur Schlüsselverwendung angibt. Die zugeordnete Datenstruktur ist ein CRYPT_BIT_BLOB (Bitfeld), das angibt, wie der Schlüssel verwendet werden kann.

Eine Erweiterung kann einem Zertifikat hinzugefügt werden, bevor es ausgestellt wird. Wenn das Zertifikat ausgestellt wird, sind alle aktivierten Erweiterungen Teil des Zertifikats. Wenn eine Erweiterung als kritisch gekennzeichnet ist, muss ihre Verwendung der verwendenden Anwendung bekannt sein, und die Anwendung muss der Absicht oder dem Wert der Erweiterung entsprechen. Zertifikatdienste ermöglichen das Festlegen von Erweiterungen für ein nicht ausgestelltes Zertifikat über methoden, die von ICertAdmin und ICertServerPolicy bereitgestellt werden. Ausführliche Informationen zu Zertifikaterweiterungen finden Sie unter CERT_EXTENSION in der CryptoAPI-Dokumentation. Informationen zu allgemeinen Datenstrukturen für Zertifikaterweiterungen finden Sie unter X.509-Zertifikaterweiterungsstrukturen.

Der Erweiterungshandler ist ein COM-Objekt, das Routinen für die Codierung komplexerer, aber häufig verwendeter Erweiterungen und Datentypen wie IA5String oder PrintableString bereitstellt.

Erweiterungen mit den Datentypen DATE, LONG und BSTR erfordern keinen Erweiterungshandler. Das Richtlinienmodul ruft einfach ICertServerPolicy::SetCertificateExtension auf, wobei der Parameter Type auf einen Wert festgelegt ist, der den Erweiterungsdatentyp darstellt: PROPTYPE_DATE, PROPTYPE_LONG oder PROPTYPE_STRING. Anschließend wird die Erweiterung an die Server-Engine übergeben. Die Server-Engine wiederum führt die ASN.1-Codierung ( Abstract Syntax Notation One ) aus, bevor die Erweiterung im Zertifikat gespeichert wird.

Erweiterungen, die über andere Datentypen als diese Standardtypen verfügen, müssen jedoch von einem Erweiterungshandler ASN.1 codiert werden, bevor das Richtlinienmodul sie an die Server-Engine übergibt. Wenn das Richtlinienmodul ICertServerPolicy::SetCertificateExtension aufruft , um eine ASN.1-codierte Erweiterung an die Server-Engine zu übergeben, muss es den Type-Parameter auf PROPTYPE_BINARY festlegen. Die Server-Engine speichert diese codierte Erweiterung dann einfach im Zertifikat.

Der Standarderweiterungshandler Certenc.dll exportiert eine Reihe von ICertEncodeXXX-Schnittstellen und kann vom Richtlinienmodul aufgerufen werden. Die erforderlichen Typinformationen sind auch in Certencl.dll enthalten, das im Platform Software Development Kit (SDK) bereitgestellt wird. Jede Schnittstelle stellt eine Encode-Methode bereit, die eine ASN.1-codierte Zertifikaterweiterung in einem Binärformat an das Richtlinienmodul zurückgibt. Das Richtlinienmodul kann dann die Erweiterung in einem Zertifikat festlegen, indem die ICertServerPolicy::SetCertificateExtension-Methode aufgerufen wird.

Weitere Informationen finden Sie unter Schreiben von benutzerdefinierten Erweiterungshandlern.