Отозвали не тот сертификат VPN? Варианты восстановления и ограничения

Кто-то отозвал сертификат в консоли CA, и теперь пользователь не может подключиться. Первый порыв — найти отмену, но в большинстве PKI её нет: отзыв — это заявленный факт о серийном номере, и поддерживаемый путь назад — новый сертификат, а не обратная запись. Пройдите проверки ниже по порядку, потому что допустимый ремонт зависит от кода причины и от того, был ли ключ когда-либо скомпрометирован.

Определите сертификат, а не человека

Обычные имена повторяются. Пользователь, перерегистрировавшийся в прошлом квартале, может иметь два сертификата с одним CN и разными серийными номерами, и отзыв одного оставляет другой работающим. Сначала установите точный объект:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Запишите серийный номер, издателя, дату отзыва и причину, указанную в CRL. Затем подтвердите, какие устройства предъявляют этот серийный номер, потому что отозванный сертификат может всё ещё быть установлен на ноутбуке, телефоне и резервном маршрутизаторе, а замена, доходящая только до одного из них, порождает второй инцидент.

Быстрая проверка поведения подтверждает состояние, ничего не меняя:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

Если она сообщает сертификат как отозванный, CRL и клиент согласны; если проверка проходит чисто, клиент у вас в руках — не отозванный, и поиск продолжается.

Проверьте, использовала ли CA приостановку или окончательный отзыв

RFC 5280 определяет certificateHold как временное состояние, а removeFromCRL как сигнал, который его снимает. Этот жизненный цикл реален, но это не универсальная кнопка отмены. Чтение кода причины говорит, собирался ли издатель вообще поддерживать снятие.

Ловушка — предполагать, что временное намерение означает временную запись. Если запись CA содержит keyCompromise или cessationOfOperation, сертификат отозван навсегда, независимо от того, что имел в виду нажавший кнопку. И наоборот, запись с пометкой certificateHold в CA, которая не реализует снятие приостановки, на практике постоянна, потому что ничто никогда не опубликует снятие.

CA на основе OpenSSL иллюстрируют предел. Команда ca принимает значения -crl_reason, включая certificateHold и removeFromCRL, но не создаёт дельта-CRL — документация OpenSSL CA указывает это ограничение для своего вывода CRL. Полный CRL, который просто пропускает серийный номер, — иная модель публикации, чем дельта, говорящая "эта запись снята", поэтому вставка removeFromCRL в VPN CA на основе OpenSSL не даёт определённого стандартами снятия.

Если ключ мог быть скомпрометирован, замените его

Отозванный сертификат — это заявление, что этому ключу больше нельзя доверять. Если отзыв был по существу правильным — ноутбук потерян, ключ скопирован на общий диск, закрытый ключ вставлен в тикет — восстановление того же сертификата отменяет решение безопасности, которое работало как задумано.

Выпустите новую пару ключей через процесс регистрации, распространите новый профиль и оставьте старый серийный номер отозванным на весь его срок. Обновите всё, что привязывает идентичность к серийному номеру или отпечатку, включая списки допуска, инвентаризацию устройств и мониторинг, ожидающий конкретный сертификат.

Аргумент удобства в пользу восстановления старого реален, но на него нужно ответить явно, а не молча. "Пользователю нужен доступ сегодня" — причина ускорить выпуск, а не причина снять отзыв ключа, за который вы не можете отчитаться.

Если это была административная ошибка, замените под контролем

Когда отзыв был просто ошибочным, а ключ никогда не компрометировался, ремонт всё равно остаётся контролируемой заменой, а не редактированием. Используйте поддерживаемый процесс издателя, сохраните серийный номер и историю выпуска нетронутыми и избегайте двух соблазнительных сокращений: переворачивания символа состояния в index.txt с R обратно на V и удаления строки выпуска, чтобы новый сертификат мог повторно использовать серийный номер.

В CA OpenSSL база данных разделена табуляцией и легко читается неправильно, что делает ручное редактирование соблазнительным:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Читайте её, не пишите в неё. Редактирование файла меняет следующий CRL без какого-либо следа аудита, и любой второй экземпляр CA или резервная копия, всё ещё содержащая исходную строку, позже разойдётся с ней.

После выпуска замены опубликуйте свежий CRL через обычный механизм и дайте клиентам его получить. Удаление CRL, сокращение срока его действия до нуля или отключение проверки отзыва в профиле клиента исправляет одного пользователя, ослабляя каждый другой отзыв, который CA когда-либо публиковала.

Подтвердите новый допуск и сохраните запись

Проверяйте новым подключением, а не сеансом, который уже был открыт. Живой туннель может не выполнить повторно проверки допуска, которые делает новое рукопожатие, а кеши CRL означают, что клиент может продолжать подключаться до обновления. Отключитесь, подключитесь снова и подтвердите в журнале сервера, какой серийный номер был допущен.

Запишите, что произошло, пока это ещё свежо: какой серийный номер отозван, кем, с какой причиной, какая замена выпущена и когда CRL была опубликована заново. Эта запись делает возможным следующий обзор отзывов и служит доказательством того, что ошибка была обработана, а не скрыта.

Для коротких приостановок в будущем используйте механизм паузы допуска, если он есть в развёртывании — учётная запись, отключённая на уровне идентичности, удалённое членство в группе, задержанный профиль клиента. Это отделяет временное политическое решение от вопроса, заслуживает ли выпущенный сертификат доверия, и именно это различие было потеряно в первый раз.