Izdavanje se zaustavlja na entry 22: invalid expiry date, a zahtjev pred vama je potpuno ispravan. Pritužba dolazi od parsera CA baze podataka, ne od CSR-a i ne od VPN klijenta koji će na kraju predstaviti certifikat. Ta razlika određuje sve nakon toga: zapis je neispravan, pa popravak pripada stanju CA, a ne zahtjevu ili konfiguraciji partnera. Numerirani zapis tretirajte kao liniju u index.txt, i problem se svodi na ograničeno pitanje o podacima s odgovorom koji se može provjeriti.

Čitajte grešku kao pritužbu na bazu podataka

Svaki openssl ca poziv prolazi kroz svoju tekstualnu bazu prije nego što bilo što potpiše. Svaka linija nosi slovo statusa, vremensku oznaku isteka, opcionu oznaku opoziva, serijski broj u heksadecimalnom obliku, naziv datoteke i subjekt. Kada se jedno polje ne može parsirati, komanda prijavi broj linije i zaustavi se umjesto da pogađa ostatak zapisa.

To zaustavljanje je zaštitno, a ne pedantno. Zapis koji alat ne može pročitati ostavlja ga bez mogućnosti da odluči postoji li traženi subjekt već, je li serijski broj dodijeljen ili što sljedeći CRL treba sadržavati. Nastavak preko loše linije proizveo bi upravo onu tihu nedosljednost koja ispliva mjesecima kasnije, obično tijekom opoziva koji nitko ne može objasniti. Čitajte poruku kao pritužbu na podatke, i istraga ostaje unutar CA direktorija.

Kopirajte stanje CA prije nego što bilo što dirnete

Napravite snimku cijelog CA direktorija, ne samo datoteke baze. Indeks, njegova datoteka atributa, datoteke serijskog broja i broja CRL-a, privatni ključ i izdani certifikati svi sudjeluju u kasnijim operacijama, a popravak koji vrati jedno, a promaši ostalo, stvara drugi incident. Koristite vlastitu rutinu sigurnosne kopije CA gdje postoji i pauzirajte zakazano izdavanje za vrijeme trajanja rada.

Zabilježite OpenSSL build i konfiguracijsku datoteku koju je neuspjela komanda stvarno učitala. Instalacije često drže više od jednog CA direktorija, a greška ima smisla samo prema bazi koju navodi odabrana konfiguracija.

Pronađite zapis i dekodirajte njegovo polje datuma

Prijavljeni broj linije broji se od prvog zapisa, pa sed -n '22p' index.txt pada na sporni zapis nakon što potvrdite da iznad njega nema praznih linija ni komentara. Ispišite tu liniju s vidljivim graničnicima, jer su tabulatori i razmaci na kraju česti i nevidljivi u običnom prozoru uređivača.

Polje isteka je vremenska oznaka čija širina zavisi od godine. Vrijednosti do 2049 zapisuju se u UTCTime kao YYMMDDHHMMSSZ, dok kasnije vrijednosti prelaze na GeneralizedTime s četveroznamenkastom godinom. Zapis koji miješa dva oblika, ili koji nosi dvoznamenkastu godinu tamo gdje parser sada očekuje četiri, pada upravo na ovom mjestu. Isto vrijedi i za odsječeno polje koje je ostavilo prekinuto pisanje.

Usporedite zapis s certifikatom na koji se odnosi, a ne s datotekom drugog CA. Potpisani certifikat je autoritet za ono što valjanost treba reći, i on već postoji kao objekt koji se može parsirati.

Popravite zapis prema potpisanom certifikatu

Pročitajte stvarne datume pomoću openssl x509 -in issued.pem -noout -dates -serial -subject. Pretvorite notAfter u širinu oznake koju vaš build piše za tu godinu, i potvrdite da se serijski broj podudara sa zapisom koji ćete uređivati prije nego što promijenite ijedan znak.

Uredite samo pokvareno polje, zadržite slovo statusa i serijski broj, a ostatak linije ostavite na miru. Ako se zapis ne može uskladiti ni s jednim potpisanim certifikatom, tretirajte ga kao zalutali zapis i povucite ga vlastitim putem opoziva CA umjesto da liniju brišete ručno.

Ne popravljajte tako što ćete skratiti datum da bi odgovarao nagađanju o godini. Rez od dva znaka nije prenosiv među buildovima i tiho mijenja valjanost koju baza prijavljuje budućim provjerama duplikata subjekta i CRL-a. Kada se izvorna vrijednost ne može povratiti, izdajte ponovno pod novim serijskim brojem i zapišite zašto je stari napušten. Revizijski trag dio je popravka, a ne papirologija oko njega.

Provjerite izdavanje i generiranje CRL-a prije nego što odete

Pokrenite jedno izdavanje s istom konfiguracijom i potvrdite da završava bez pritužbe na broj linije. Zatim generirajte CRL s openssl ca -gencrl -config openssl.cnf i provjerite da se parsira, jer oštećeni zapis često ispliva upravo tamo, a ne tijekom potpisivanja.

Pregledajte novi certifikat s openssl x509 -noout -dates -serial i usporedite ga s linijom koju je CA upravo napisao. Potvrdite da se slovo statusa i datum isteka slažu s certifikatom, i potvrdite da openssl verify -CAfile ca.pem issued.pem vraća bez greške. Zatim vratite zakazano izdavanje i promatrajte prvo pokretanje, jer će se druga neispravna linija odmah najaviti.

Povezani članci