Відкликали не той сертифікат 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 опубліковано знову. Цей запис уможливлює наступний огляд відкликань і є доказом того, що помилку було опрацьовано, а не приховано.

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