openssl ca: недійсна дата завершення в index.txt і як це виправити

Запуск видачі зупиняється на entry 22: invalid expiry date, а запит перед вами цілком гаразд. Скарга походить від розбирача бази даних ЦС, а не від CSR і не від клієнта VPN, який зрештою подасть сертифікат. Ця різниця визначає все подальше: запис пошкоджено, тому виправлення належить до стану ЦС, а не до запиту чи конфігурації партнера. Розглядайте пронумерований запис як рядок у index.txt, і проблема зводиться до обмеженого питання про дані з відповіддю, яку можна перевірити.

Читайте помилку як скаргу на базу даних

Кожен openssl ca виклик проходить своєю текстовою базою, перш ніж щось підписати. Кожен рядок містить літеру стану, позначку часу завершення, необов'язкову позначку відкликання, серійний номер у шістнадцятковому вигляді, ім'я файлу та суб'єкт. Коли одне поле не розбирається, команда повідомляє номер рядка і зупиняється, замість того щоб вгадувати решту запису.

Ця зупинка захисна, а не педантична. Запис, який інструмент не може прочитати, позбавляє його можливості вирішити, чи вже існує запитаний суб'єкт, чи вже видано серійний номер і що має містити наступний CRL. Продовження через зіпсований рядок породило б саме ту тиху неузгодженість, яка випливає за місяці, зазвичай під час відкликання, яке ніхто не може пояснити. Читайте повідомлення як скаргу на дані, і розслідування залишиться всередині каталогу ЦС.

Скопіюйте стан ЦС, перш ніж щось чіпати

Зробіть знімок усього каталогу ЦС, а не лише файлу бази даних. Індекс, його файл атрибутів, файли серійного номера та номера CRL, закритий ключ і видані сертифікати беруть участь у подальших операціях, а виправлення, яке відновлює одне й оминає інші, створює другий інцидент. Використовуйте власну процедуру резервного копіювання ЦС, якщо вона є, і призупиніть планову видачу на час роботи.

Запишіть збірку OpenSSL і файл конфігурації, які фактично завантажила невдала команда. Інсталяції часто тримають більше одного каталогу ЦС, і помилка має сенс лише щодо бази, яку називає вибрана конфігурація.

Знайдіть запис і декодуйте його поле дати

Зазначений номер рядка відраховується від першого запису, тому sed -n '22p' index.txt потрапляє на проблемний запис після того, як ви переконаєтеся, що вище немає порожніх рядків чи коментарів. Надрукуйте цей рядок із видимими роздільниками, бо табуляції та пробіли в кінці трапляються часто і невидимі у звичайному вікні редактора.

Поле завершення — це позначка часу, ширина якої залежить від року. Значення до 2049 записуються в UTCTime як YYMMDDHHMMSSZ, а пізніші значення переходять на GeneralizedTime із чотиризначним роком. Запис, який змішує дві форми або несе двозначний рік там, де розбирач тепер очікує чотири, зазнає невдачі саме в цьому місці. Так само і обрізане поле, залишене перерваним записом.

Порівнюйте запис із сертифікатом, на який він посилається, а не з файлом іншого ЦС. Підписаний сертифікат — це джерело істини про те, що має казати термін дії, і він уже існує як об'єкт, який можна розібрати.

Виправте запис за підписаним сертифікатом

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

Редагуйте лише пошкоджене поле, збережіть літеру стану й серійний номер, а решту рядка залиште як є. Якщо запис не вдається узгодити з жодним підписаним сертифікатом, вважайте його блудним і виведіть його власним шляхом відкликання ЦС, а не видаляйте рядок вручну.

Не виправляйте, обрізаючи дату під припущення про рік. Обрізка на два символи непереносна між збірками й тихо змінює термін дії, який база повідомляє майбутнім перевіркам на дублікат суб'єкта та CRL. Коли початкове значення не відновлюється, перевипустіть із новим серійним номером і запишіть, чому старий залишено. Аудиторський слід — частина виправлення, а не паперова робота навколо нього.

Перевірте видачу й генерацію CRL, перш ніж піти

Виконайте одну видачу з тією ж конфігурацією і переконайтеся, що вона завершується без скарги на номер рядка. Потім згенеруйте CRL за допомогою openssl ca -gencrl -config openssl.cnf і перевірте, що він розбирається, бо пошкоджений запис часто виявляється саме там, а не під час підписування.

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