CERTUTIL/CERTREQ - CSR erstellen

Verschiedene Supportfälle mit "Zertifikaten" haben mich dazu gebracht, auf dieser Seite einen Weg zu beschreiben, den ich nun bevorzug gehe, um, die Kontrolle über die Zertifikatsanforderung zu haben. Allzu oft konnte ein Zertifikat nicht ausgestellt werden oder das anscheinend korrekt installierte Zertifikat war nicht für den geplanten Zweck geeignet oder freigeschaltet. Das passiert immer öfter, wenn z.B. CNG-Key-Speicher genutzt werden, aber die Applikationen damit nicht umgehen können.

Basiswissen

Zertifikate sind wichtig, wenn Datenübertragungen verschlüsselt stattfinden sollen und die Endpunkte beweisen wollen, dass Sie auch die richtigen Endpunkte sind. Dazu dienen Zertifikate, die neben den Namen, eine Gültigkeitsdauer und einem Public-Key auch eine Zertifizierungsinformation enthalten. Sie sind von einer Zertifizierungsstelle "unterschrieben", die auf dem Client vertrauenswürdig eingestuft ist. Das Zertifikat enthält nicht den privaten Schlüssel, der im Idealfall den Server nie verlässt. Um SSL zu nutzen, muss also ein Schlüsselpaar (Private/Public-Key) ermittelt werden. Der Public Key wird dann mit einigen zusätzlichen Informationen ergänzt und als Certificate Signing Request (CSR) an eine Zertifizierungsstelle übermittelt. Diese prüft die Daten und signiert dann den Request. Das Ergebnis ist dann das Zertifikat, welches auf dem Computer dann wieder eingespielt werden kann. Soweit der Schnelldurchlauf.

Mit oder ohne Assistent ?

Sowohl Exchange als auch Lync/Skype für Business haben eigene Assistenten, die Anforderung von Zertifikaten "vereinfachen". Und auch für den IIS gibt es einen passenden Assistenten. Wann immer es einen Assistenten gibt, würde ich diesen auch benutzen aber dennoch alle Optionen genau anschauen.

Knifflig wird es immer dann, denn die Zertifizierungsstelle nicht den "Standard" folgt, sondern eigene Mindeststandards voraussetzt. Das kann z.B. die Schlüssellänge (1024bit ist auf jeden Fall zu Kurz, aber oft der Default beim Request) sein. Aber auch der Name des Templates ist eine kritische Komponente. Die meisten Assistenten setzen hier einfach "Webserver" ein, was für die öffentlichen Zertifizierungsstellen kein Problem ist.

Wer aber eine eigene PKI auf Basis von Windows betreibt, muss ein neues Template anlegen, um eine längere Gültigkeit zu erreichen. Dieses neue Template kann natürlich "Webserver" ersetzen. Oft ist das aber nicht der Fall.

Prüfliste

Wenn Sie also ein Zertifikat anfordern müssen und nicht die Windows native Enrollment-Wege nutzen können, dann erfragen Sie am besten vorher bim Zertifikatsstellenbetreiber die erforderlichen Angaben für einen Zertifikatsantrag (CSR). Hierzu zählen:

Wert Standard Bemerkungen

Template-Name

WebServer

Ein Windows CA-Administrator kann in der Regel nicht das Template beim Signieren ändern. Zu dem im Request enthaltenen Namen muss es also ein Template bei der PKI geben. Sie können aber den Namen auch "leer" lassen. Dann kann der Betreiber selbst ein Template zuweisen

Key Format

CNG oder Legacy

Seit Windows 2008 (?) kann der private Schlüssel noch besser "gesichert" werden. Leider unterstützen auch 2015 die meisten Applikationen noch keinen CNG-Schlüssel-Store. Stellen Sie beim Request sicher, dass Sie den richtigen Zertifikatsspeicher verwenden.

Key-Länge

1024

Mittlerweile erwarten fast alle Zertifizierungsstellen mindestens 2048bit. Ihre Schlüssellänge muss mindestens der Länge im Template entsprechen

Exportierbar

Nein

Wenn Sie das Zertifikat auf mehreren Servern verwenden wollen, z.B.: das OAUTH-Zertifikat im Skype für Business Pool, dann muss der private Key exportierbar gekennzeichnet sein. Das "sieht" aber auch eine PKI und kann dann das Ausstellen verhindern.

SAN-Namen

Nein

Exchange, Lync, Skype für Business und viele andere Dienste nutzen zusätzliche Namen. Sei es um mehrere Domains zu unterscheiden oder mehrere Server mit dem gleichen Zertifikate zu betreiben. Die PKI muss das dann zulassen und ihre Request muss dies enthalten

Dies ist nur eine erste Liste, die sicher nicht vollständig ist. Dazu gibt es nämlich eine ganze Menge an EinstellMöglichkeiten. Starten Sie doch einfach mal eine MMC und erstellen Sie eine Zertifikatsanforderung ohne Template und schauen Sie sich die verschiedenen Optionen an. Hier ein paar  Bilder quasi zur Abschreckung:

Und das ist nur eine Teilmenge der Optionen. Es gibt aber durchaus Videos und How-To's, wie sie mit der MMC erfolgreich ein Zertifikat anfordern können. Allerdings ist nach meiner Ansicht das Fehlerpotential sehr hoch und Sie sollten sich genau eine Checkliste machen, damit sie alle Optionen korrekt ausgefüllt haben.

Request erstellen

Die meisten Produkte erlauben eine Generierung einer Zertifikatsanforderung direkt auf dem Endgerät. Das ist auch sinnvoll, weil damit das Gerät auch den privaten und öffentlichen Schlüssel auf dem System selbst errechnet und speziell der private Schlüssel nie das Gerät verlässt. Es gibt jede Menge Anleitungen der Hersteller und insbesondere öffentlicher PKIs

Wenn wir den Request auf Windows erstellen wollen, dann ist CERTREQ.EXE eine Option, welche aber eine INF-Datei mit den Daten zum Zertifikat benötigt. Hier ein Beispiel für ein Webserver-Zertifikat.

[Version]
Signature= "$Signature" 

[NewRequest]
Subject = "CN=www.msxfaq.de, OU=IZ, O=MSXFAQ, L=Paderborn, S=NRW, C=DE"
KeySpec = 1
KeyLength = 2048
KeyUsage = 0xa0
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

[Extensions] 
2.5.29.17="{Text}"
_continue_="dns=www.msxfaq.de&"
_continue_="dns=server1.msxfaq.de&"
_continue_="dns=server2.msxfaq.de" 

[RequestAttributes] 
CertificateTemplate=Webserver47Tage

Im Beispiel habe ich noch die SAN-Namen konfiguriert und das Template vorgegeben. Dies ist natürlich optional 

Hinweis: Bis Windows 2003R2 mussten die Werte im Extension Feld als Base64-codierter String abgelegt werden.

Diese Datei kann ich dann per Kommandozeile ausführen lassen:

In der INF-Datei steht ein "MachineKeySet = TRUE". In dem Fall müssen Sie den Befehl als Admin ausführen.

# Requests erstellen (Parameter in der INF)
certreq.exe -new {Informationsdatei}.inf {Zertifikatantrag}.req

Die REQ-Datei enthält dann den BASE64-codierten Request, wie ihn jede PKI verstehen sollte.

Anzeige eines Request

Wenn Sie eine REQ-Datei enthalten und die Daten anzeigen wollen, dann ist CertUtil ein Helfer.

certutil -dump {Zertifikatanforderung} 

Hier eine gekürzte Ausgabe:

C:\>certutil -dump c:\test\cert.req
PKCS10-Zertifikatanforderung:
Version: 1
Antragsteller:
    CN=www.msxfaq.de
    OU=IZ
    O=MSXFAQ
    L=Paderborn
    S=NRW
    C=DE
  Namenshash (sha1): c84c2489041e847a1650db362b9702530f938cf0
  Namenshash (md5): 4d0d2f0a1b8682e613e34a9aa3e29c96

Öffentlicher Schlüssel-Algorithmus:
    Algorithmus Objekt-ID: 1.2.840.113549.1.1.1 RSA
    Algorithmusparameter:
    05 00
Länge des öffentlichen Schlüssels: 2048 Bits
Öffentlicher Schlüssel: Nicht verwendete Bits = 0
    0000  30 82 01 0a 02 82 01 01  00 ca 05 de 80 ca ef a1
.....
    0100  51 5e 2f b2 d6 c8 9d 29  45 02 03 01 00 01
Anforderungsattribute: 4
  4 Attribute:

  Attribut[0]: 1.3.6.1.4.1.311.13.2.3 (Betriebssystemversion)
    Wert [0][0], Länge = e
        10.0.26200.2

  Attribut[1]: 1.3.6.1.4.1.311.21.20 (Clientinformationen)
    Wert [1][0], Länge = 2a
    Client-ID: = 9
    ClientIdCertReq -- 9
    Benutzer: FC-T14G5\fcarius
    Computer: FC-T14G5
    Status: certreq

  Attribut[2]: 1.2.840.113549.1.9.14 (Zertifikaterweiterungen)
    Wert [2][0], Länge = 46
Zertifikaterweiterungen: 3
    2.5.29.15: Kennzeichen = 1(Kritisch), Länge = 4
    Schlüsselverwendung
        Digitale Signatur, Schlüsselverschlüsselung (a0)

    2.5.29.37: Kennzeichen = 0, Länge = c
    Erweiterte Schlüsselverwendung
        Serverauthentifizierung (1.3.6.1.5.5.7.3.1)

    2.5.29.14: Kennzeichen = 0, Länge = 16
    Schlüsselkennung des Antragstellers
        00263879fc1709e7c117ae3c98e131e31d6db334


  Attribut[3]: 1.3.6.1.4.1.311.13.2.2 (Kryptografiedienstanbieter der Registrierung)
    Wert [3][0], Länge = 64
    Kryptografiedienstanbieterinformationen
    Schlüsselspez. = 1
    Anbieter = Microsoft RSA SChannel Cryptographic Provider
    Signatur: Nicht verwendete Bits=0
Signaturalgorithmus:
    Algorithmus Objekt-ID: 1.2.840.113549.1.1.5 sha1RSA
    Algorithmusparameter:
    05 00
Signatur: Nicht verwendete Bits=0
    0000  66 04 cd 4d 44 f2 df 89  c3 bd a1 78 6c 50 1a 63
....
    00f0  14 42 f1 a3 2e 2d 7e d3  35 85 b8 3f b5 0c 52 74
Signatur stimmt mit dem öffentlichen Schlüssel überein.
Schlüssel-ID-Hash(rfc-sha1): 00263879fc1709e7c117ae3c98e131e31d6db334
Schlüssel-ID-Hash(sha1): 36f1afd846aa8927a28a286c17f50add386c2712
Schlüssel-ID-Hash(bcrypt-sha1): 7f03bc372785dea63d65434b2b12c8f7e38dd173
Schlüssel-ID-Hash(bcrypt-sha256): c6c25c432098a7d7fd74a3e801d4e6f09505ad5d39c4017b8c78e40f733ce6c8
CertUtil: -dump-Befehl wurde erfolgreich ausgeführt.

Für einen PKI-Administrator ist es wichtig hier die angefragten Verwendungszwecken "Serverauthentifizierung (1.3.6.1.5.5.7.3.1)" und die Namen im Antragsteller "Antragsteller: CN=www.msxfaq.de..." zu prüfen, ehe wir das Zertifikat ausstellen

Natürlich gibt es auch sehr viele Webdienste, die einen Certificate Signing Request (CSR) decodieren und anzeigen können. Suchen Sie einfach nach CSR-Decoder. Im CSR steht kein "Geheimnis", welches so verraten werden könnte.

 Anfordern mit CERTUTIL

Die Anforderung als CSR-Datei kann nun vom PKI-Admin bei der Zertifizierungsstelle eingereicht werden. Eine Windows PKI erlaubt hier gleich mehrere Wege. Nicht alle Wege haben Sie aber auch installiert.

  • CA-MMC per RPC
  • CERTUTIL per RPC
  • Web Ennrollment (Formular)
    Zusatzrolle, die nicht installiert sein sollte, da sie mittlerweile nicht mehr funktioniert. Sie basiert auf ASP und ActiveX und wurde seit vielen Jahren nicht aktualisiert.
  • NDES/SCEP - Simple Certificate Enrollment Process
  • ACME nur mit 3rd Party AddOny

Wenn ich eine REQ-Datei automatisch einreichen will, dann geht das wieder per CERTREQ

certreq `
   -submit `
   -config "CA.msxfaq.de\MSXFAQ Issuing CA 1" `
   -attrib "CertificateTemplate:Webserver47Tage" `
   www.msxfaq.de.req

Wenn ich Parameter wie die CA und das Template angebe, dann überstimme ich Angaben im REQ-File.

 

 

 

ToDo:  Was passiert, wenn die PKI erst bestätigen muss.

 

 

certreq -retrieve {Anforderungs-ID}

 

 

Wenn Sie aber den Weg über die Kommandozeile gehen wollen, dann habe ich hier eine INF-Vorlage als Muster zur Anforderung eines SAN-Zertifikats mit 2048bit Schlüssellänge, exportierbaren privatem Key und einem eigenen Template "Webserver5Jahre":

 

Send a manually created certificate request to a certification authority
https://www.gradenegger.eu/en/send-a-manually-created-certificate-request-to-a-certification-body/  

 

Zertifikate einspielen

Auf dem Endgerät, auf dem der CSR erstellt wurde, wartet der PrivateKey auf das passende Zertifikat. Von der CA haben wir eine CER-Datei enthalten, welche wir wie folgt nun importieren:

 

certreq.exe -Accept CAResponse.cer

 

 

Get-Certificate 
https://learn.microsoft.com/en-us/powershell/module/pki/get-certificate

PKIClient Module
https://learn.microsoft.com/en-us/powershell/module/pki/

 

 

https://learn.microsoft.com/en-us/powershell/module/pkiclient/get-certificate 

Weitere Links