Springe zum Inhalt

Kategorie: Zertifikats-Lebenszyklus

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.

 

Veröffentlicht am Hinterlasse einen Kommentar zu Nicht ob, sondern wann ist die Frage

Seit über 30 Jahren existiert die Idee vom Quantencomputer, der Verschlüsselungsverfahren wie RSA und ECDSA brechen könnte. Auch wenn Skeptiker bezweifeln, ob solch ein Quantencomputer jemals relevant wird, spielt diese Frage für die Planung des Umstiegs auf die seit dem vergangenen Jahr standardisierten Post-Quanten-Kryptoverfahren (PQC) nicht die entscheidende Rolle.

Die Frage ist vielmehr, wann die Aufsichtsbehörden und Fachgremien den Umstieg auf PQC in ihren Compliance-Anforderungen und Best-Practice-Empfehlungen festschreiben werden. Moscas Ungleichung bringt das zugrunde liegende Dilemma auf den Punkt: Wenn der Zeitbedarf für die Migration und der Zeitraum, in dem herkömmlich verschlüsselte oder signierte Daten noch sicher bleiben müssen, zusammengenommen die geschätzte Zeit bis zur Verfügbarkeit eines ausreichenden Quantencomputers erreichen, entsteht Handlungsdruck.

Das BSI ging 2023 noch davon aus, dass letzterer Zeitraum 20 Jahre beträgt. In seinem am 02.01.2025 veröffentlichten Update zum Stand 2024 wurde die Schätzung jedoch auf 16 Jahre, also bis 2040, verkürzt. In den USA fordert die NSA für "National Security Systems", den Umstieg bei TLS-Schlüsselaustausch und Firmware-Signaturen sofort zu beginnen, für PKIs spätestens 2030.

Verantwortliche für Schlüsselmanagementsysteme, PKIs und ähnliche kryptografische Infrastrukturen sollten daher frühzeitig über eine Migration zu PQC nachdenken und ggf. mit den notwendigen Vorbereitungen beginnen.

Veröffentlicht am Hinterlasse einen Kommentar zu Auf die Kürze kommt es an

Nachdem Google 2023 mit einem ähnlichen Vor­haben scheiterte, brachte Apple am 08.10.2024 einen neuen Vorschlag im CA/Browser-Forum ein. Ziel ist es, die maximale Gültigkeitsdauer von öffent­lich gültigen TLS-Serverzertifikaten schrittweise auf 45 Tage zu begrenzen.

Primär soll dadurch die Relevanz von Sperrmechanis­men, denen Browser-Hersteller ohnehin skeptisch gegenüberstehen, verringert werden. Dies senkt das Risiko durch überflüssige oder gar kompromittierte, aber nicht gesperrte Ser­verzertifikate.

Gleichzeitig soll die „Cache“-Zeit für eine einmal er­folgte Validierung von OV/EV-Angaben auf 366 Tage reduziert werden. Für DNS-Namen oder IP-Adressen soll diese Zeit sogar auf 10 Tage verkürzt werden. Bisher dürfen Trustcenter einmal validierte Unter­lagen wie Handelsregisterauszüge bis zu 825 Tage lang wiederverwenden und sich so die aufwändige erneute Prüfung bei einer Verlängerung ersparen.

Technisch würde dadurch das ACME-Protokoll weiter an Bedeutung gewinnen, mit dem Zertifikats­ver­längerungen alle 30 bis 40 Tage auto­matisiert und dabei stets die DNS-Namen validiert werden können.

Der Vorschlag würde zudem die Position der Brow­ser-Hersteller gegenüber problematischen Trustcen­tern stärken. Nach einem Ver­trauensentzug stünden deren Kunden noch schneller ohne gültige Zertifikate da. Wer Dutzende öffentlich gültiger Serverzertifikate nutzt, ist gut beraten, einen Zweitlieferanten in petto zu haben.

Darüber hinaus könnte die kürzere Gültigkeit den Übergang zu PQC-Zertifikaten erleichtern, der ab etwa 2030 zu erwarten ist.

 

Veröffentlicht am Hinterlasse einen Kommentar zu Rechtzeitig, frühzeitig, vorzeitig

Nachdem ich im vorigen Beitrag mehmals das Wort „Karenz“ benutzt habe, möchte ich noch eine Bemerkung hinterherschicken:

Zertifikate, die vor dem Ablauf stehen (und tun sie das nicht alle?), aber weiterhin benötigt werden, müssen rechtzeitig erneuert werden, um Betriebsstörungen zu vermeiden. Häufig –sicherlich auch motiviert durch das klassische Gebührenmodell öffentlicher Trustcenter, bei dem jedes TLS-Serverzertifikat einzeln berechnet wurde– wird „rechtzeitig“ interpretiert als „so kurz wie vertretbar von dem Ablauftermin“.

Zuverlässiger ist es allerdings, so frühzeitig zu erneuern, dass ein umbeabsichtigter Ablauf mit hoher Sicherheit vermieden wird. Also längere Karenzzeiten einplanen, die man vielleicht eher in Monaten zählt als in Wochen. Zumal die Serverzertifikate einer internen PKI in der Regel gar nicht separat berechnet werden und auch viele kommerzielle Trustcenter inzwischen einen Zeitraum für die Versorgung mit Zertifikaten und nicht ein einzelnes Zertifikat als Abrechnungsgrundlage anbieten.

Und letztlich verbieten weder PKI-Standards noch Best-Practice-Anforderungen, Zertifikate lange vor ihrem Ablauftermin - man könnte also sagen vorzeitig - zu erneuern. Wer in puncto Verfügbarkeit auf der sicheren Seite bleiben will, sollte das Zertifikat seines Servers während des jährlichen geplanten Wartungsfensters erneuern, selbst wenn das vorhandene Serverzertifikat noch über ein Jahr gültig wäre.
Natürlich sollte man das nicht länger benötigte, vorherige Zertifikat anschließend sperren. Genau für diesen Fall sieht X.509 seit über 20 Jahren den Sperrgrund superseded vor.

Merke: PKI ist eines der wenigen(?) Themen, bei denen die Vokabel „vorzeitig“ positiv besetzt sein sollte.

Veröffentlicht am Hinterlasse einen Kommentar zu Absolution oder Ansporn?

Anfang Mai 2019 bekamen Firefox-Anwender weltweit (in ihrer jeweils eingestellten Sprache) die folgende Warnmeldung zu sehen:

Dazu kam es weil Firefox nur solche Add-ons ausführt, die vor der Bereitstellung von ihren Erstellern mit einer Code-Signatur versehen wurden. Nun war am 04.05.2019 das Zertifikat einer Intermediate-CA im Zertifikatspfad der Code-Signing-Zertifikate für Add-on Entwickler abgelaufen und die Code-Signaturen wurden nicht mehr als gültig validiert - ergo wie vorgesehen die betreffenden (d. h. hier: alle) Add-ons nicht mehr geladen.

Der eine Fehler, den man den Entwickern bei Mozilla ankreiden kann, ist es, als Stichpunkt für die Validierung den Zeitpunkt anzusetzen, an dem das betreffende Add-on geladen werden soll, mithin den Startzeitpunkt des Browsers. Jedes Signaturzertifikat wird irgendwann einmal ablaufen. Häufig will man aber auch danach noch das betreffende Dokument, den Code oder was immer sonst signiert wurde, validieren. Daher ist in aller Regel der sinnvolle Stichpunkt, zu dem eine Signatur und das verwendete Signaturzertifikat validiert werden müssen, der Zeitpunkt, zu dem die Signatur angebracht wurde (also die Gretchenfrage: War das Signaturzertifikat zu diesem rückdatierten Stichpunkt bereits abgelaufen oder nicht?). Microsofts Authenticode Code-Signaturverfahren nutzt dazu Timestamps. Auch wer selbst keinen Timestamp-Server betreibt kann das Verfahren einfach nutzen, da bis heute viele kommerzielle Trustcenter sehr freizügig und kostenlos Timestamps erstellen, durch die man gerade angebrachte Signaturen mit den (nicht nur) bei ihnen gekauften Code-Signatur-Zertifikaten dauerhaft machen kann.

Die weitaus größere Blamage ist es, dass das Intermediate-CA Zertifikat überhaupt ohne eine rechtzeitige vorherige Erneuerung ablaufen konnte. Zumal den Mozilla-Leuten das gleiche Malheur bereits drei Jahre zuvor unterlaufen war.

Zum Hintergrund, weswegen abglaufene CA-Zertifikate und besonders CRLs immer wieder vorkommen, muss ich etwas weiter ausholen. Root- und Intermediate-CAs, die nicht wie Issuings-CAs zum Erstellen von Nutzer- oder Geräte-Zertifikaten im Tagesgeschäft permanent erreichbar sein müssen, werden aus guten (Sicherheits-)Gründen in der Regel komplett offline betrieben.

Als Beispiel für die Risiken einer Online-CA sei auf das Debakel des niederländischen Trustcenters DigiNotar im Jahre 2011 hingewiesen. Dort waren Angreifer vom Internet aus über ein internes Management-Netzwerk bis zum aktivierten Hardware-Security-Modul (HSM) einer CA vorgedrungen. Und ein einmal aktiviertes HSM ist im wesentlichen ein Frankierautomat, der brav alles abstempelt, was man ihm vorlegt. In diesem Fall stempelte es handgefertigte Zertifikatsrümpfe der Angreifer zu öffentlich gültigen Zertifikaten. (Mein Allzeit-Favorit ist übrigens das Wildcard-Zertifikat für *.*.com .)

Der Pferdefuß von „komplett offline und nur physisch erreichbar“ ist nun aber leider „nur physisch erreichbar per manuellem Zugriff der Bediener“. Das heißt, der Mensch und seine Zeitplanung sind ein unabdingbares Element des Erneuerungsprozesses. Übliches Vorgehen sind Wiedervorlage-Termine im Kalender und einige Wochen Karenzzeit vor dem endgültigen Ablauf, für den Fall, dass beim eigentlich vorgesehenen Termin etwas dazwischen kommt. Manchmal kommt dann eben bis nach dem Ende der Karenzzeit etwas dazwischen...

Ist das Mozilla-Malheur nun - getreu dem Motto „Wenn selbst denen das passiert ...“ eine Absolution für uns alle, denen schon einmal unbemerkt ein Server- oder CA-Zertifikat oder eine CRL abgelaufen ist? Oder eher ein Ansporn, einfach besser aufzupassen als „die“?

Meiner Meinung nach weder noch. Die richtige Konsequenz aus derlei Fällen ist einerseits, die Erneuerung von Zertifikaten und CRL zu automatisieren, wo immer das möglich ist, sprich: bei online betriebenen Issuing-CAs. Andererseits sollte man den Gültigkeitsstatus von Zertifikaten und CRLs aktiv überwachen und dabei bereits beim Beginn einer Karenzfrist, die noch Zeit zur Reaktion lässt, zu alarmieren. Damit können dann auch die wohlweislich manuellen Erneuerngsprozesse bei einer offline betriebenen CA nicht so leicht im anderen Tagesgeschäft des Bedienpersonals untergehen.

Also Automatisierung und Alarmierung anstatt Absolution.
(Ja, eigentlich: Monitoring und Alerting, aber das würde mir die Alliteration kaputt machen.)