Отменен VPN сертификат все още се свързва? Проверете прилагането на CRL

Отменихте сертификата, генерирахте нов списък, а старият профил все още вдига тунел. Самото отменяне не е счупено: CRL е подписано изявление, че серийният номер вече не е валиден, и променя достъпа само когато компонентът, който завършва TLS, го зареди, за правилния издател, преди да вземе решението за приемане. Там се намират повечето от тези случаи, и затова отменянето и отказът са два различни факти.

Преминете през петте проверки по-долу по ред и спрете на първата, която не е в сила, защото всяка следваща предполага, че предишните са верни.

Проверете кой компонент взема решението за приемане

Определете процеса, който валидира клиентския сертификат, защото само този процес може да наложи списък. На сървър OpenVPN това е самият демон, конфигуриран с crl-verify. В ocserv това е редът crl в ocserv.conf. В strongSwan входовете са заредените CRL заедно с strictcrlpolicy. Прокси или устройство, което завършва TLS пред VPN, също може да е истинският проверяващ, и ако е, демонът зад него никога не вижда клиентския сертификат.

WireGuard принадлежи към друга категория. Той няма сертификати и няма списък за отмяна; peer се приема чрез публичния си ключ в конфигурацията, така че прекратяването на достъпа означава премахване на този ключ. Ако търсите CRL в инсталация само с WireGuard, този механизъм там го няма.

Внимавайте и за капана от страна на клиента. Клиент, който отказва връзка, защото не харесва сървърния сертификат, прилага веригата на сървъра, а не отменя собствените си удостоверения. Потребителски сертификат се отменя само там, където този потребителски сертификат се валидира, а това е почти винаги страната на сървъра.

Проверете за кой издател е подписан списъкът

CRL е ограничен до един издаващ CA. С корен и междинен CA листата идват от междинния, така че списъкът, който има значение, е CRL на междинния; списъкът на корена не казва нищо за тези листа. Проверяващ, насочен към грешния файл, го парсва весело, не намира съвпадащ запис и приема всичко.

Потвърдете сдвояването, преди да докоснете демона. Издателят в сертификата трябва да съвпада със subject на списъка:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Когато и двете идват от един и същ CA, серийният номер, отпечатан за сертификата, е стойността, която трябва да се появи в списъка. Ако не съвпадат, държите грешен CRL или грешно копие от него.

Валидността принадлежи към същата проверка. nextUpdate в миналото прави списъка остарял, а проверяващ, който се проваля затворено, тогава ще отхвърли всеки клиент вместо само отменения.

Проверете дали серийният номер е в копието, което демонът е заредил

Отменянето записва запис в базата данни на CA, а повторното генериране записва нов файл. Нито едно от двете действия не стига до работещ демон, който е заредил старото копие при стартиране. Изведете списъка и потърсете серийния номер:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

След това проверете как вашата реализация приема файла. OpenVPN чете път, подаден на crl-verify, веднъж при стартиране, така че нов списък изисква рестартиране или сигнал за рестартиране; същата опция, насочена към директория, се препрочита при всяка връзка, и затова съществува режимът на директория. strongSwan трябва да презареди своите удостоверения, например с swanctl --load-creds. Това, че файлът на диска е правилен, и това, че проверяващият го използва, са два различни факта.

Проверете политиката за липсващ или изтекъл списък

Това е решението, което много инсталации никога не вземат изрично, и то определя дали отменянето ви защитава, или заключва всички навън. Fail-closed означава, че без използваема информация за отмяна настъпва отказ; fail-open означава, че проверяващият продължава без нея. strongSwan излага избора като strictcrlpolicy. OpenVPN с crl-verify отказва да стартира на файл, който не може да прочете или парсне, а изтеклият списък се появява като TLS грешка за проверка на изтекъл CRL, вместо като тихо приемане.

Която и посока да изберете, автоматизацията е по-важна от избора: задача, която регенерира CRL преди nextUpdate, и предупреждение, когато внедреното копие остарее, пречат и на двете политики да станат инцидент. Онлайн проверката с OCSP премества свежестта към responder, но важи същото правило, защото проверяващ, който не е конфигуриран да проверява отговора, не променя нищо.

Проверете активната сесия, след това копията на ключа

Отменянето се оценява по време на валидирането на сертификата, което се случва при свързване и при повторно договаряне. Установена сесия продължава, докато не преговаря отново, а стойността по подразбиране на OpenVPN е веднъж на час с reneg-sec 3600. Ако човекът трябва да е извън мрежата веднага, прекратете сесията заедно с публикуването на списъка и след това потвърдете, че повторното свързване се отхвърля.

Отделете удостоверението от неговите копия. Изтриването на профил на един лаптоп не пречи на друго копие на същия частен ключ да се автентикира; отменянето е това, което прави всяко копие безполезно, и само когато предишните проверки са в сила. Дайте на резервното устройство собствен сертификат, за да може едното да се отмени, без да се докосва другото.

Преди да го обявите за завършено: валидиращият компонент е идентифициран, издателят на списъка съвпада с издателя на листото, отмененият сериен номер се намира в копието, което демонът действително е заредил, политиката за липсващи или изтекли списъци е умишлена и наблюдавана, и активната сесия е прекратена, вместо да се изчаква. Форматите зад всичко това са специфицирани в RFC 5280.