openssl ca: nieprawidłowa data ważności w index.txt i jak ją naprawić

Przebieg wydawania zatrzymuje się na entry 22: invalid expiry date, a wniosek, który masz przed sobą, jest całkowicie w porządku. Skarga pochodzi z parsera bazy danych CA, nie z CSR ani z klienta VPN, który w końcu przedstawi certyfikat. To rozróżnienie decyduje o wszystkim dalej: rekord jest zniekształcony, więc naprawa należy do stanu CA, a nie do wniosku ani do konfiguracji partnera. Numerowany wpis traktuj jako linię w index.txt, a problem zwęża się do ograniczonego pytania o dane z odpowiedzią, którą można sprawdzić.

Czytaj błąd jako skargę na bazę danych

Każde openssl ca wywołanie przechodzi przez swoją tekstową bazę danych, zanim cokolwiek podpisze. Każda linia zawiera literę stanu, znacznik czasu wygaśnięcia, opcjonalny znacznik odwołania, numer seryjny w hex, nazwę pliku i podmiot. Gdy jedno pole nie daje się przeanalizować, polecenie zgłasza numer linii i zatrzymuje się, zamiast zgadywać resztę rekordu.

To zatrzymanie jest ochronne, a nie pedantyczne. Rekord, którego narzędzie nie potrafi odczytać, pozostawia je bez możliwości rozstrzygnięcia, czy żądany podmiot już istnieje, czy numer seryjny został wydany i co powinna zawierać następna CRL. Przejście obok uszkodzonej linii wytworzyłoby dokładnie tę cichą niespójność, która ujawnia się miesiące później, zwykle podczas odwołania, którego nikt nie potrafi wyjaśnić. Czytaj komunikat jako skargę na dane, a śledztwo pozostanie w katalogu CA.

Skopiuj stan CA, zanim czegokolwiek dotkniesz

Zrób migawkę całego katalogu CA, nie tylko pliku bazy danych. Indeks, jego plik atrybutów, pliki numeru seryjnego i numeru CRL, klucz prywatny i wydane certyfikaty biorą udział w późniejszych operacjach, a naprawa, która przywraca jeden i pomija pozostałe, tworzy drugi incydent. Gdzie istnieje, użyj własnej procedury kopii zapasowej CA, i wstrzymaj zaplanowane wydawanie na czas pracy.

Zapisz kompilację OpenSSL i plik konfiguracyjny, które nieudane polecenie faktycznie wczytało. Instalacje często trzymają więcej niż jeden katalog CA, a błąd ma znaczenie tylko wobec bazy danych wskazywanej przez wybraną konfigurację.

Znajdź wpis i zdekoduj jego pole daty

Zgłoszony numer linii liczy się od pierwszego rekordu, więc sed -n '22p' index.txt trafia na problematyczny wpis po potwierdzeniu, że powyżej nie ma pustych linii ani komentarzy. Wydrukuj tę linię z widocznymi separatorami, bo tabulatory i końcowe spacje są częste i niewidoczne w zwykłym oknie edytora.

Pole wygaśnięcia to znacznik czasu, którego szerokość zależy od roku. Wartości do 2049 zapisuje się w UTCTime jako YYMMDDHHMMSSZ, natomiast późniejsze wartości przechodzą na GeneralizedTime z czterocyfrowym rokiem. Rekord, który miesza obie formy lub niesie dwucyfrowy rok tam, gdzie parser oczekuje teraz czterech cyfr, zawodzi dokładnie w tym miejscu. Podobnie przycięte pole pozostawione przez przerwany zapis.

Porównuj rekord z certyfikatem, na który się powołuje, a nie z plikiem innej CA. Podpisany certyfikat jest władzą w kwestii tego, co powinna mówić ważność, i już istnieje jako obiekt możliwy do przeanalizowania.

Napraw rekord według podpisanego certyfikatu

Odczytaj rzeczywiste daty za pomocą openssl x509 -in issued.pem -noout -dates -serial -subject. Przekształć notAfter na szerokość znacznika, którą twoja kompilacja zapisuje dla tego roku, i przed zmianą choćby jednego znaku potwierdź, że numer seryjny zgadza się z wpisem, który zamierzasz edytować.

Edytuj tylko uszkodzone pole, zachowaj literę stanu i numer seryjny, a resztę linii zostaw w spokoju. Jeśli rekordu nie da się uzgodnić z żadnym podpisanym certyfikatem, potraktuj go jako wpis zabłąkany i wycofaj go własną ścieżką odwołania CA, zamiast usuwać linię ręcznie.

Nie naprawiaj, przycinając datę tak, by pasowała do domysłu o roku. Cięcie o dwa znaki nie jest przenośne między kompilacjami i po cichu zmienia ważność, którą baza danych podaje przyszłym kontrolom zduplikowanego podmiotu i CRL. Gdy pierwotnej wartości nie da się odzyskać, wydaj ponownie pod nowym numerem seryjnym i zapisz, dlaczego stary został porzucony. Ścieżka audytu jest częścią naprawy, a nie papierologią wokół niej.

Sprawdź wydawanie i generowanie CRL, zanim odejdziesz

Uruchom jedno wydawanie z tą samą konfiguracją i potwierdź, że kończy się bez skargi o numer linii. Następnie wygeneruj CRL poleceniem openssl ca -gencrl -config openssl.cnf i sprawdź, że daje się przeanalizować, bo uszkodzony rekord często wychodzi właśnie tam, a nie podczas podpisywania.

Sprawdź nowy certyfikat poleceniem openssl x509 -noout -dates -serial i porównaj go z linią, którą CA właśnie zapisała. Potwierdź, że litera stanu i data wygaśnięcia zgadzają się z certyfikatem, i potwierdź, że openssl verify -CAfile ca.pem issued.pem wraca bez błędu. Potem przywróć zaplanowane wydawanie i obserwuj pierwszy przebieg, bo druga zniekształcona linia zgłosi się natychmiast.