... sollte man ein Zertifikat, das nicht mit Sperrgrund certificateHold (siehe den vorigen Blogbeitrag) suspendiert ist, wieder entsperren. Das verstößt gegen PKI-Standards, Best-Practice und die guten Manieren.
[Einschub: Ein bereits abgelaufenes gesperrtes Zertifikat nicht mehr auf einer neuen Sperrliste aufzuführen ist dagegen nicht unbedingt ehrenrührig - zumindest solange es sich nicht um ein Signaturzertifikat handelt.]
Aber wie ich von Juristen gelernt habe, bedeutet "grundsätzlich" in deren Sprachgebrauch, dass begründete Ausnahmen möglich sind. Im Fall von gesperrten Zertifikaten findet sich eine mögliche Ausnahme im Bereich von Device Management Systemen.
Solche Systeme -bspw. Intune, aber auch andere- können oft auch selbsttätig Zertifikate sperren, wenn das Gerät, auf das sie ein bestimmtes Zertifikat ausgerollt haben, als defekt/verloren/gestohlen markiert wird. Das ist generell eine gute Idee.
Leider gehen manche dieser Systeme -bspw. Intune, aber auch andere- dann davon aus, dass sie für die von Ihnen verwalteten Zertifikate keine Sperrlisten oder OCSP-Status mehr prüfen müssen. In der fälschlichen Annahme, dass nur sie selbst diese Zertifikate im Fall des Falles sperren und daher a priori schon über den Sperrstatus Bescheid wissen.
So rollt Intune Zertifikate, die ein angeschlossener PKCS-Connector einmal stellvertretend als PKCS#12-Datei besorgt und zu Intune hochgeladen hat, munter weiter an das betreffende Gerät aus, selbst wenn ein Certificate Manager der zugehörigen CA es gesperrt hat. Natürlich kann das Gerät dann nicht viel mit diesem Zertifikat anfangen, aber das bekommt Intune nicht direkt mit.
In derartigen Fällen kann es das Einfachste sein, wenn der Klügere(?) nachgibt und die CA das Zertifikat entsperrt, damit der echte und der vermeintliche Sperrstatus in der PKI bzw. dem Device Management System wieder konsistent sind. Natürlich sollte man das Zertifikat dann unverzüglich über das Device Management wieder sperren, um die guten Sitten, die Konformität zu PKI-Standards und Best-Practice zu wahren.
Ist die betreffende CA eine Microsoft-CA (vulgo ADCS) gibt es einen einfachen Trick, mit dem man das tun kann:
Der Befehl
CertUtil -revoke <Seriennummer> <Sperrgrund>ist dazu gedacht, ein Zertifikat per Kommandozeile zu sperren und dabei optional einen Sperrgrund anzugeben. Oder um ein suspendiertes Zertifikat wieder zu entsperren, indem man als Sperrgrund unrevoke oder -1 angibt.
Man kann ihn aber auch dazu nutzen, einem bereits gesperrten Zertifikat einen geänderten Sperrgrund zu verpassen, indem man es noch einmal sperrt.
Dabei hat Microsoft die offensichtlichen Missbrauchsmöglichkeiten abgefangen:
- unrevoke geht nur, wenn der bestehende Sperrgrund certificateHold (microsoftisch: CRL_REASON_CERTIFICATE_HOLD oder standardkonform kurz 6) ist.
- Das Ändern eines anderen Sperrgrunds zu CRL_REASON_CERTIFICATE_HOLD geht nicht.
Was aber versehentlich oder bewusst nicht abgefangen wird, ist, einen bestehenden Sperrgrund in removeFromCRL (microsoftisch: CRL_REASON_REMOVE_FROM_CRL oder kurz 8) abzuändern.
Ein Zertifikat mit diesem Sperrgrund taucht durch seinen Status zwar in der CA-Managementkonsole zwar weiterhin unter Revoked Certificates (oder, wenn man es deutsch lokalisiert mag: Gesperrte Zertifikate) auf - aber nicht mehr auf der nächsten erstellten CRL. Für Relying Parties, die diese CRL auswerten, ist es faktisch entsperrt.
Wir merken uns also für Not- und Sonderfälle:
CertUtil -revoke <Seriennummer> 8