openssl ca: невалидна дата на изтичане в index.txt и как да я поправим

Изпълнение за издаване спира на entry 22: invalid expiry date, а заявката пред вас е напълно изправна. Оплакването идва от анализатора на базата данни на CA, не от CSR и не от VPN клиента, който в крайна сметка ще представи сертификата. Това разграничение определя всичко след него: записът е повреден, затова поправката принадлежи на състоянието на CA, а не на заявката или на конфигурацията на партньора. Третирайте номерирания запис като ред в index.txt, и проблемът се свива до ограничен въпрос за данни с проверим отговор.

Четете грешката като оплакване за базата данни

Всяко openssl ca извикване обхожда текстовата си база, преди да подпише каквото и да е. Всеки ред съдържа буква за състояние, времеви печат на изтичане, незадължителен печат на отмяна, сериен номер в шестнадесетичен вид, име на файл и субект. Когато едно поле не се разчита, командата съобщава номера на реда и спира, вместо да гадае останалата част от записа.

Това спиране е предпазно, а не педантично. Запис, който инструментът не може да прочете, го оставя без възможност да реши дали заявеният субект вече съществува, дали сериен номер е бил издаден или какво трябва да съдържа следващият CRL. Продължаването след лош ред би създало точно това тихо несъответствие, което изплува месеци по-късно, обикновено при отмяна, която никой не може да обясни. Четете съобщението като оплакване за данните и разследването остава в директорията на CA.

Копирайте състоянието на CA, преди да пипате каквото и да е

Направете снимка на цялата директория на CA, не само на файла с базата. Индексът, файлът с атрибутите му, файловете със серийния номер и номера на CRL, частният ключ и издадените сертификати участват в следващите операции, а поправка, която възстановява едно и пропуска другите, създава втори инцидент. Използвайте собствената процедура за архив на CA, където има такава, и спрете планираното издаване за времетраенето на работата.

Запишете изданието на OpenSSL и конфигурационния файл, които неуспешната команда действително е заредила. Инсталациите често пазят повече от една директория на CA и грешката има смисъл само спрямо базата, която избраната конфигурация посочва.

Намерете записа и декодирайте полето за дата

Съобщеният номер на ред се брои от първия запис, така че sed -n '22p' index.txt попада на проблемния запис, след като сте потвърдили, че над него няма празни редове или коментари. Отпечатайте този ред с видими разделители, защото табулациите и интервалите в края са чести и невидими в обикновен прозорец на редактор.

Полето за изтичане е времеви печат, чиято ширина зависи от годината. Стойности до 2049 се записват в UTCTime като YYMMDDHHMMSSZ, а по-късните стойности преминават към GeneralizedTime с четирицифрена година. Запис, който смесва двете форми или носи двуцифрена година там, където анализаторът вече очаква четири, се проваля точно в тази точка. Същото важи и за отрязано поле, останало от прекъснат запис.

Сравнявайте записа със сертификата, за който се отнася, а не с файла на друг CA. Подписаният сертификат е авторитетът за това какво трябва да казва валидността и той вече съществува като обект, който може да се анализира.

Поправете записа спрямо подписания сертификат

Прочетете истинските дати с openssl x509 -in issued.pem -noout -dates -serial -subject. Преобразувайте notAfter в ширината на печата, която вашата сборка записва за тази година, и потвърдете, че серийният номер съвпада със записа, който ще редактирате, преди да промените и един знак.

Редактирайте само счупеното поле, запазете буквата за състояние и серийния номер и не пипайте останалата част от реда. Ако записът не може да се съгласува с нито един подписан сертификат, третирайте го като случаен запис и го изведете по собствения път за отмяна на CA, вместо да изтривате реда на ръка.

Не поправяйте, като отрязвате дата, за да пасне на догадка за годината. Отрязване от два знака не е преносимо между сборки и тихо променя валидността, която базата съобщава на бъдещи проверки за дублиран субект и CRL. Когато първоначалната стойност е невъзстановима, издайте наново с нов сериен номер и запишете защо старият е бил изоставен. Одитната следа е част от поправката, а не документация около нея.

Проверете издаването и генерирането на CRL, преди да си тръгнете

Изпълнете едно издаване със същата конфигурация и потвърдете, че завършва без оплакване за номер на ред. След това генерирайте CRL с openssl ca -gencrl -config openssl.cnf и проверете, че се анализира, защото повреденият запис често изплува там, а не по време на подписването.

Прегледайте новия сертификат с openssl x509 -noout -dates -serial и го сравнете с реда, който CA току-що написа. Потвърдете, че буквата за състояние и датата на изтичане съвпадат със сертификата, и че openssl verify -CAfile ca.pem issued.pem се връща без грешка. След това възстановете планираното издаване и наблюдавайте първото изпълнение, защото втори повреден ред ще се обади веднага.