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