openssl ca: ungültiges Ablaufdatum in index.txt und wie man es repariert

Ein Ausstellungslauf bricht mit entry 22: invalid expiry date ab, und die Anfrage vor Ihnen ist völlig in Ordnung. Die Beschwerde kommt vom Parser der CA-Datenbank, nicht von der CSR und nicht vom VPN-Client, der das Zertifikat später vorlegen wird. Diese Unterscheidung entscheidet alles Weitere: Ein Datensatz ist fehlerhaft, also gehört die Reparatur in den CA-Zustand und nicht in die Anfrage oder die Peer-Konfiguration. Behandeln Sie den nummerierten Eintrag als Zeile in index.txt, und das Problem schrumpft auf eine begrenzte Datenfrage mit einer prüfbaren Antwort.

Lesen Sie den Fehler als Beschwerde über die Datenbank

Jeder openssl ca Aufruf durchläuft seine Textdatenbank, bevor er irgendetwas signiert. Jede Zeile enthält einen Statusbuchstaben, einen Ablaufzeitstempel, optional einen Sperrzeitstempel, eine Seriennummer in Hex, einen Dateinamen und den Betreff. Wenn ein Feld nicht geparst wird, meldet der Befehl die Zeilennummer und bricht ab, statt den Rest des Datensatzes zu raten.

Dieser Abbruch ist schützend und nicht pedantisch. Ein Datensatz, den das Werkzeug nicht lesen kann, lässt es nicht entscheiden, ob der angefragte Betreff bereits existiert, ob eine Seriennummer vergeben wurde oder was die nächste CRL enthalten soll. Über eine kaputte Zeile hinweg weiterzulaufen würde genau jene stille Inkonsistenz erzeugen, die Monate später auftaucht, meist während einer Sperrung, die niemand erklären kann. Lesen Sie die Meldung als Beschwerde über die Daten, und die Untersuchung bleibt im CA-Verzeichnis.

Kopieren Sie den CA-Zustand, bevor Sie etwas anfassen

Erstellen Sie einen Schnappschuss des gesamten CA-Verzeichnisses, nicht nur der Datenbankdatei. Der Index, seine Attributdatei, die Dateien für Seriennummer und CRL-Nummer, der private Schlüssel und die ausgestellten Zertifikate sind alle an späteren Vorgängen beteiligt, und eine Reparatur, die eines wiederherstellt und die anderen auslässt, erzeugt einen zweiten Vorfall. Nutzen Sie die eigene Sicherungsroutine der CA, wo es eine gibt, und pausieren Sie die geplante Ausstellung für die Dauer der Arbeit.

Notieren Sie den OpenSSL-Build und die Konfigurationsdatei, die der fehlgeschlagene Befehl tatsächlich geladen hat. Installationen halten oft mehr als ein CA-Verzeichnis, und der Fehler bedeutet nur etwas gegenüber der Datenbank, die die gewählte Konfiguration benennt.

Finden Sie den Eintrag und dekodieren Sie sein Datumsfeld

Die gemeldete Zeilennummer zählt ab dem ersten Datensatz, also trifft sed -n '22p' index.txt auf den beanstandeten Eintrag, sobald Sie bestätigt haben, dass darüber keine Leer- oder Kommentarzeilen stehen. Geben Sie die Zeile mit sichtbaren Trennzeichen aus, denn Tabulatoren und nachgestellte Leerzeichen sind häufig und in einem gewöhnlichen Editorfenster unsichtbar.

Das Ablauffeld ist ein Zeitstempel, dessen Breite vom Jahr abhängt. Werte bis 2049 werden in UTCTime als YYMMDDHHMMSSZ geschrieben, während spätere Werte auf GeneralizedTime mit vierstelliger Jahreszahl wechseln. Ein Datensatz, der beide Formen mischt oder eine zweistellige Jahreszahl trägt, wo der Parser nun vier erwartet, scheitert genau an dieser Stelle. Ebenso ein abgeschnittenes Feld, das ein unterbrochener Schreibvorgang hinterlassen hat.

Vergleichen Sie den Datensatz mit dem Zertifikat, auf das er verweist, und nicht mit der Datei einer anderen CA. Das signierte Zertifikat ist die Autorität dafür, was die Gültigkeit sagen soll, und es existiert bereits als parsebares Objekt.

Reparieren Sie den Datensatz anhand des signierten Zertifikats

Lesen Sie die tatsächlichen Daten mit openssl x509 -in issued.pem -noout -dates -serial -subject. Rechnen Sie notAfter in die Stempelbreite um, die Ihr Build für dieses Jahr schreibt, und bestätigen Sie, dass die Seriennummer zum Eintrag passt, den Sie gleich bearbeiten, bevor Sie ein Zeichen ändern.

Bearbeiten Sie nur das defekte Feld, behalten Sie den Statusbuchstaben und die Seriennummer, und lassen Sie den Rest der Zeile in Ruhe. Lässt sich der Datensatz mit keinem signierten Zertifikat in Einklang bringen, behandeln Sie ihn als verirrten Eintrag und ziehen Sie ihn über den eigenen Sperrpfad der CA zurück, statt die Zeile von Hand zu löschen.

Reparieren Sie nicht, indem Sie ein Datum zuschneiden, damit es zu einer Vermutung über das Jahr passt. Ein Schnitt um zwei Zeichen ist zwischen Builds nicht portabel und verändert stillschweigend die Gültigkeit, die die Datenbank künftigen Prüfungen auf doppelte Betreffe und CRL meldet. Wenn der ursprüngliche Wert nicht wiederherstellbar ist, stellen Sie unter einer neuen Seriennummer erneut aus und notieren Sie, warum die alte aufgegeben wurde. Die Prüfspur gehört zur Reparatur und ist kein Papierkram drumherum.

Prüfen Sie Ausstellung und CRL-Erzeugung, bevor Sie gehen

Führen Sie eine Ausstellung mit derselben Konfiguration aus und bestätigen Sie, dass sie ohne Beanstandung einer Zeilennummer durchläuft. Erzeugen Sie dann eine CRL mit openssl ca -gencrl -config openssl.cnf und prüfen Sie, dass sie sich parsen lässt, denn ein beschädigter Datensatz tritt oft dort zutage und nicht beim Signieren.

Untersuchen Sie das neue Zertifikat mit openssl x509 -noout -dates -serial und vergleichen Sie es mit der Zeile, die die CA gerade geschrieben hat. Bestätigen Sie, dass Statusbuchstabe und Ablaufdatum zum Zertifikat passen, und bestätigen Sie, dass openssl verify -CAfile ca.pem issued.pem ohne Fehler zurückkommt. Stellen Sie dann die geplante Ausstellung wieder her und beobachten Sie den ersten Lauf, denn eine zweite fehlerhafte Zeile meldet sich sofort.