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

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

Подобни статии