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 rechtzeitigerneuert 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ühzeitigzu 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.
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.)
Wenn man den Zertifikatsspeicher eines neu installierten Windows-Rechners anschaut, dann wird man feststellen, dass nur noch ein gutes Dutzend Root-CA-Zertifikate (microsoftisch-deutsch: "vertrauenswürdige Stammzertifikate") enthalten sind. Das geht übrigens seit Windows 8 sehr schnell über den folgenden Kommandozeilen-Aufruf:
Der Nebel lichtet sich ein wenig, wenn man den Rechner eine Weile in Betrieb hat und feststellt, dass nach dem Besuch von Webseiten, Installation von signierten Programmen usw. unvermutet weitere Root-CAs im Store auftauchen.
Es gibt also einen in Windows eingebauten Nachlade-Mechanismus für Root-Zertifikate. Warum Microsoft nicht gleich alle Root-Zertifikate installiert, darüber kann man trefflich spekulieren. Neben der überschaubareren Optik, die dem Betrachter ein besseres Gefühl suggeriert, wem er da eigentlich alles vertraut, könnte es daran liegen, dass einige Komponenten des Betriebssystems vielleicht mit soooo vielen Root-Zertifikaten gar nicht zurecht kommen.
Der Nachlade-Mechanismus funktioniert grob wie folgt:
Wenn ein Zertifikat (bspw. das Serverzertifikat einer Webseite) validiert wird, versucht Windows, eine Zertifikatskette bis zu einer vertrauenswürdigen Root zu finden.
Falls die Zertifikatskette bis zu einem der installierten Root-Zertifikate geschlossen werden kann, dann wird sie nach Gültigkeit und Sperrstatus validiert.
Falls nicht, dann wird geprüft, ob der Hashwert des Issuer-Namens im letzten Zertifikat, zu dem kein vertrauenswürdiger Aussteller mehr im lokalen Store gefunden werden kann, in einer Liste hinterlegter Hashwerte von Issuern aus dem Root Certificate Program auftaucht.
Wenn ja, dann wird das betreffende Root-Zertifikat von einem Server aus dem Window Update System nachgeladen. (Notabene: Obwohl Windows Update Server mit verwendet werden, ist der Mechanismus selbst davon unabhängig, ob Windows Update aktiviert ist oder nicht.)
Aus Sicherheitssicht ist dieses Nachladen von Root-Zertifikaten wenig bedenklich, weil alle Trustcenter, deren Root-CAs am Programm teilnehmen gleichermaßen streng geprüft wurden. Allenfalls einem unbedarften Anwender, der unter diesen Trustcentern eine eigene Auswahl treffen will, spuckt Microsoft damit in die Suppe.
Es gibt jedoch einen (seltenen) Fall, in dem dieser Mechanismus versagt: Wenn in einem Firmen-Netzwerk - oder künftig vielleicht verstärkt in einem Industrie-4.0 OT-Netzwerk?! - die Firewall so dicht ist, dass sie den Windows-Clients jegliche Kommunikation mit Servern im Internet verwehrt. Damit die Administratoren solcher Systeme einen eigenen, internen Download-Server für die Root-Zertifikate aufsetzen können, dessen Adresse sie dann - wie sollte es anders sein - per Group Policy intern verteilen, gibt es einen Weg, um alle Root-Zertifikate von Windows Update manuell herunterzuladen. Das kommt natürlich auch all denen entgegen, die ähnlich neugierig sind wie ich:
certutil -syncWithWU <Directory>
In dem angegebenen Directory finden sich nach erfolgreichem Abschluss des Kommandos nicht nur alle für Microsoft Windows gültigen Root-Zertifikate, sondern auch eine Certificate-Store-Datei mit all jenen Zertifikaten, denen Windows auf gar keinen Fall vertraut. Aber das ist wahrscheinlich ein Thema für einen anderen Blogbeitrag...
Diese Frage ist ja nicht so ganz unwichtig für ein Blog, das sich diesem Thema widmen will.
Laut Duden Regel 42 (welche Nummer auch sonst??) werden Aneinanderreihungen und Zusammensetzungen mit Wortgruppen aus Fremdwörtern mit Bindestrich geschrieben. Korrekt hieße es also "Public-Key-Infrastruktur". Das sieht aber je nach Auge des Betrachters nicht nur ungewohnt bis hässlich aus, diese Schreibweise hat sich auch so im deutschen Sprachraum nie wirklich eingebürgert.
Also will ich es in diesem kleinen Blog so halten, wie es auch das Bundesamt für Sicherheit in der Informationstechnik höchstoffiziell unter dem Bundesadler und dem schwarz-rot-goldenen Säulenelement tut und die übliche getrennte Schreibweise "Public Key Infrastruktur" verwenden.
