Отповикан 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.