openssl ca: ongeldige vervaldatum in index.txt en hoe je die herstelt

Een uitgeefrun stopt met entry 22: invalid expiry date, terwijl het verzoek voor je neus volstrekt in orde is. De klacht komt van de parser van de CA-database, niet van de CSR en niet van de VPN-client die het certificaat uiteindelijk zal presenteren. Dat onderscheid bepaalt alles daarna: een record is misvormd, dus de reparatie hoort in de CA-status en niet in het verzoek of de peer-configuratie. Behandel de genummerde vermelding als een regel in index.txt, en het probleem krimpt tot een afgebakende datavraag met een antwoord dat je kunt controleren.

Lees de fout als een klacht over de database

Elke openssl ca aanroep loopt door zijn tekstdatabase voordat hij iets ondertekent. Elke regel bevat een statusletter, een verlooptijdstempel, een optioneel intrekkingsstempel, een serienummer in hex, een bestandsnaam en het subject. Als één veld niet te parseren is, meldt het commando het regelnummer en stopt het in plaats van de rest van het record te raden.

Die stop is beschermend en niet pedant. Een record dat de tool niet kan lezen, laat hem niet kunnen beslissen of het gevraagde subject al bestaat, of een serienummer is uitgegeven, of wat de volgende CRL moet bevatten. Doorlopen na een slechte regel zou precies die stille inconsistentie opleveren die maanden later opduikt, meestal tijdens een intrekking die niemand kan verklaren. Lees het bericht als een klacht over de gegevens, en het onderzoek blijft binnen de CA-map.

Kopieer de CA-status voordat je iets aanraakt

Maak een momentopname van de hele CA-map, niet alleen van het databasebestand. De index, het attribuutbestand, de bestanden voor serienummer en CRL-nummer, de privésleutel en de uitgegeven certificaten doen allemaal mee in latere bewerkingen, en een reparatie die er één herstelt en de andere mist, veroorzaakt een tweede incident. Gebruik de eigen back-uproutine van de CA waar die bestaat, en pauzeer de geplande uitgifte voor de duur van het werk.

Noteer de OpenSSL-build en het configuratiebestand dat het mislukte commando werkelijk heeft geladen. Installaties houden vaak meer dan één CA-map aan, en de fout betekent alleen iets ten opzichte van de database die de gekozen configuratie noemt.

Vind de vermelding en decodeer het datumveld

Het gemelde regelnummer telt vanaf het eerste record, dus sed -n '22p' index.txt komt op de bewuste vermelding terecht zodra je hebt bevestigd dat er geen lege of commentaarregels boven staan. Druk die regel af met zichtbare scheidingstekens, want tabs en spaties aan het eind komen veel voor en zijn onzichtbaar in een gewoon editorvenster.

Het verloopveld is een tijdstempel waarvan de breedte van het jaar afhangt. Waarden tot en met 2049 worden in UTCTime geschreven als YYMMDDHHMMSSZ, terwijl latere waarden overgaan op GeneralizedTime met een viercijferig jaar. Een record dat de twee vormen mengt, of dat een tweecijferig jaar draagt waar de parser nu vier cijfers verwacht, faalt precies op dit punt. Net als een afgekapt veld dat een onderbroken schrijfactie heeft achtergelaten.

Vergelijk het record met het certificaat waarnaar het verwijst, niet met het bestand van een andere CA. Het ondertekende certificaat is de autoriteit voor wat de geldigheid zou moeten zeggen, en het bestaat al als een te parseren object.

Repareer het record aan de hand van het ondertekende certificaat

Lees de echte datums met openssl x509 -in issued.pem -noout -dates -serial -subject. Zet notAfter om naar de stempelbreedte die jouw build voor dat jaar schrijft, en bevestig dat het serienummer overeenkomt met de vermelding die je gaat bewerken voordat je één teken verandert.

Bewerk alleen het kapotte veld, houd de statusletter en het serienummer, en laat de rest van de regel met rust. Als het record met geen enkel ondertekend certificaat te verzoenen is, behandel het dan als een verdwaalde vermelding en trek het terug via het eigen intrekkingspad van de CA in plaats van de regel met de hand te verwijderen.

Repareer niet door een datum bij te knippen zodat die bij een gok over het jaar past. Een knip van twee tekens is niet overdraagbaar tussen builds, en hij verandert stil de geldigheid die de database aan toekomstige controles op dubbele subjects en CRL rapporteert. Als de oorspronkelijke waarde onherstelbaar is, geef dan opnieuw uit onder een nieuw serienummer en schrijf op waarom de oude is losgelaten. Het auditspoor is deel van de reparatie, geen papierwerk eromheen.

Controleer uitgifte en CRL-generatie voordat je weggaat

Draai één uitgifte met dezelfde configuratie en bevestig dat die zonder klacht over een regelnummer voltooit. Genereer daarna een CRL met openssl ca -gencrl -config openssl.cnf en controleer dat die te parseren is, want een beschadigd record komt vaak daar boven water en niet tijdens het ondertekenen.

Inspecteer het nieuwe certificaat met openssl x509 -noout -dates -serial en vergelijk het met de regel die de CA zojuist schreef. Bevestig dat de statusletter en de vervaldatum met het certificaat overeenkomen, en bevestig dat openssl verify -CAfile ca.pem issued.pem zonder fout terugkomt. Herstel daarna de geplande uitgifte en houd de eerste run in de gaten, want een tweede misvormde regel kondigt zich meteen aan.