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 возвращается без ошибки. Затем восстановите плановый выпуск и проследите за первым запуском, потому что вторая испорченная строка заявит о себе сразу.