Was tun, wenn Zertifikate nicht akzeptiert werden?
Mein Name ist Thomas und ich werde mich hier vorrangig melden, wenn es was Interessantes zu PKI Themen zu sagen gibt.
Gelegentlich kommt es vor, dass ein Zertifikat mit kryptischen Fehlermeldungen abgewiesen wird. Häufigste Ursache für Zertifikatsprobleme stellt die Sperrliste dar. In dieser Certificate Revocation List (ab jetzt CRL) veröffentlicht jeder Zertifikatsserver die von ihm gesperrten Zertifikate. Ist diese Liste nicht erreichbar, kommt es zu einer Fehlermeldung und das Zertifikat wird als ungültig angesehen. Deshalb überprüft das Cryptography API (ab jetzt CAPI) als erstes diese Sperrlisten.
Wie können wir CRL Fehler troubleshooten?
Hierzu eignet sich am besten das Tool CERTUTIL. Wichtig ist, dass für die nachfolgenden Schritte immer die Server Variante verwendet wird. Also besteht der erste Schritt darin, CERTUTIL.EXE und die zusätzlich benötigten CERTADM.DLL sowie die CERTCLI.DLL in ein eigenes Verzeichnis auf die lokale Festplatte des Clients zu kopieren. Bitte niemals die Client-Version aus dem System32 Verzeichnis überschreiben!!!
Befinden sie die drei Dateien im gewünschten Verzeichnis brauchen wir dort auch noch das zu untersuchende Zertifikat. Dieses lässt sich entweder aus der MMC oder dem Internet Explorer als .CER Datei abspeichern. Jetzt haben wir für den entscheidenden Befehl alles beieinander. Er lautet
certutil –verify –urlfetch <MeinZertifikat>.cer > certutil.txt
Was tut dieses Kommando?
Es baut die Zertifikatskette vom Endzertifkat, das kann zum Beispiel ein Benutzerzertifikat oder SSL-Zertifikat sein, bis zu einer Trusted Root Certification Authority auf und überprüft für alle Zertifikate, ob deren CDP (CRL Distribution Point) URLs erreichbar sind.
Die CRL bezogene Ausgabe finden wir in der Textdatei für jedes Zertifikat unter:
---------------- Certificate CDP ----------------
Verified "Base CRL (1357)" Time: 0
--> LDAP ist OK und so kann die Basis CRL verifiziert werden.
[0.0] ldap:///CN=MyComp%20Corporate%20Issuing%20CA(1),CN=MyCASrv,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=int?certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified "Delta CRL (1357)" Time: 0
--> Ebenso kann die Delta CRL über LDAP verifiziert werden.
[0.1.0] https://pki.corp.int/certdata/MyComp%20Corporate%20Issuing%20CA(1)+.crl
Verified "Base CRL (1357)" Time: 0
Failed "CDP" Time: 0
Error retrieving URL: Error 0x80190194 (-2145844844)
[0.1.0] https://pki.corp.int/certdata/MyComp%20Corporate%20Issuing%20CA(1)+.crl
--> HTTP funktioniert zwar für die Basis CRL, nicht aber für die Delta CRL. Hier hat der IIS7 unter Windows 2008 ein Problem weil das für das „+“ Zeichen in der Delta CRL nötige Double Escaping nicht konfiguriert wurde.
Also müssen wir im nächsten Schritt testen, ob die URL via Internet Explorer angesprochen werden kann. Wenn dieses im Sicherheitskontext des Benutzers möglich ist, muss außerdem überprüft werden, ob die selbe Prozedur auch unter dem Local System Konto funktioniert. Hierzu startet man zunächst einen Command Prompt mithilfe des AT Befehls (unter Vista den Task Scheduler verwenden.):
AT hh:mm /interactive cmd
und startet dann mit "iexplore" den Internet Explorer oder wiederum certutil - verify -urlfetch <MeinZertifikat>.cer
Wenn sich mehrere Zertifikate in der Kette befinden, kommt es auf den jeweiligen Kontext an. Die einzelnen Zertifikate werden durch den CertContext Parameter eingeleitet, dem normalerweise zwei Zahlen in eckigen Klammern folgen.
CertContext[0][0] : ist immer das an CERTUTIL übergebene Zertifikat
CertContext[0][1] : ist das Zertifikat, das die CA autorisiert, die das übergebene Zertifikat ausgestellt hat
CertContext[0][2] : ist das Zertifikat der CA, die wiederum diese übergeordnete CA autorisiert hat. Meistens stammt es von einer Trusted Root CA, deren Zertifikat sich, da es self signed ist, im Trusted Root Store des Computers oder des betreffenden Benutzers befinden muss.
Mit diesen Informationen kann man sich jetzt einigermaßen kommod durch die CRLs hangeln.
Servus
Thomas