Springe zum Inhalt

Monat: Februar 2025

Veröffentlicht am Hinterlasse einen Kommentar zu Grundsätzlich nie…

... 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

Veröffentlicht am Hinterlasse einen Kommentar zu Der wohl sperrigste aller Sperrgründe

Wenn man ein Zertifikat sperrt (manche sagen auch "widerruft", vom englischen revocation), dann gehört es zum guten Ton, einen Sperrgrund anzugeben. Damit kann der geneigte Leser der CRL dann einschätzen, ob ein potenziell panikauslösendes Sicherheitsproblem vorliegt (Sperrgründe: keyCompromise, cACompromise oder für Attributzertifikate, die in der Praxis praktisch nicht verwendet werden: aACompromise).

Oder ob -wie in der Mehrzahl der Fälle- das Zertifikat einfach vorzeitig ersetzt wurde, der Server abgebaut, ein Name oder eine E-Mail-Adresse geändert, der Zertifikatsinhaber gekündigt hat oder dergleichen - weswegen aber noch nicht gleich die Alarmglocken schrillen sollten.

Zu diesem Zweck haben die Schöpfer von X.509 in der Version von 1997 erst acht, im Jahr 2000 dann zwei weitere Zahlenwerte spendiert, die jeweils für einen vordefinierten Sperrgrund stehen. Die 0 ist dabei der Notausgang für Bequemlichkeit oder Unwissen: unspecified. Und interessanterweise wurde die 7 nie offiziell vergeben, was vielleicht mit dem Sonderstatus der 8 zu tun hat, auf die wir gleich noch zu sprechen kommen werden.

Ein Spezialfall ist der Sperrgrund certificateHold (die 6, manchmal auch nur kurz "Hold" genannt). Er kommt aus dem Kontext von Zertifikaten auf Smartcards, Token, Ausweisen und dergleichen. Wie ich vor Jahren aus gut unterrichteten (Werkschutz-)Kreisen gehört habe, ist in etwa 40% der Fälle, in denen ein Betriebsausweis an der Pforte als verlustig gemeldet wird, dieser Ausweis nicht tatsächlich für immer verloren. Sondern taucht binnen ein oder zwei Wochen aus seinem Versteck in einer Manteltasche, hinter einem Sofa oder wo auch immer wieder auf. In solchen Fällen spart es spürbar an Prozesskosten für Personalisierung und Neuausgabe, wenn der Ausweis nicht sofort annulliert, sondern erst einmal für einige Tage deaktiviert und ein günstigerer temporärer Ersatzausweis ausgegeben wird. Taucht der Originalausweis nicht mehr auf, wird er endgültig gesperrt und neu ausgegeben - wird er aber gefunden, dann kann man ihn einfach wieder zulassen und weiter nutzen.

Damit dies auch für etwaige Zertifikate auf dem Ausweis oder Token funktioniert gibt es den Sperrgrund certificateHold, die temporäre Suspendierung. Er ist der einzige Grund, bei dem ein Zertifikat erlaubterweise wieder entsperrt werden darf.
Ein Problem ergab sich dabei aber für die optionalen Delta-CRLs, über die einer vollständigen Base-CRL zwischenzeitlich gesperrte Zertifikate hinzugefügt werden können (ähnlich wie bei einem inkrementellen Backup die neu angelegten Dateien). Wie sagt man, dass ein bestimmter Eintrag aus der Delta-CRL der Base-CRL nicht hinzugefügt, sondern -sofern das Zertifikate dort als certificateHold suspendiert ist- für die Sperrprüfung wieder aus ihr entfernt werden soll? Über den titelgebenden sperrigen Sperrgrund Nummer 8 - removeFromCRL, der strenggenommen eher ein Ent-Sperrgrund ist.