Новите VPN најави не успеваат додека сертификатите се валидни: проверете го CRL

Сертификати со преостанати месеци и најави што веднаш не успеваат укажуваат на два различни објекти со два различни часовници. Серверот ги одбива врските затоа што листата со отповикани сертификати што ја консултира ја поминала сопствената дата на истекување, а не затоа што сертификатите на корисниците застарeле. Обновувањето на кориснички сертификат не прави ништо за таа листа.

Одвојувањето на двата распореди е целата дијагноза и го менува тоа каков треба да биде поправката.

Два часовници, и само еден од нив е сертификатот

Сертификатот носи прозорец на валидност. Листата за отповикување на сертификати носи сопствен прозорец, плус издавач и потпис, и проверувачите одбиваат да ѝ веруваат на листа чие време за следно ажурирање поминало. Кога тоа се случува, клиентот прикажува сосема валиден сертификат, а серверот сепак ја прекинува врската со порака за листата. Корисниците ја читаат таа порака како „сертификатот истече“, што го испраќа барањето за обновување на погрешно место.

Двата објекти имаат и различни сопственици: сертификатот доаѓа од CA што го издала, додека листата се генерира по распоред од оној што ја води таа CA. Корисникот не може да ја освежи, а повторното издавање сертификати не може да ја продолжи.

Прочитајте ја листата што услугата навистина ја вчитува

Започнете од конфигурацијата што работи, а не од датотеката што ја очекувате. Патеката на crl-verify може да биде апсолутна, релативна во однос на профилот или копија вградена во слика, и проверувачот ја чита таа копија. Проверете ја на самото место со openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate и споредете ги датумите со часовникот на серверот.

Потоа потврдете дека датотеката е навистина таа што се користи: проверете го нејзиниот потпис со openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, што пријавува резултат од проверка наместо тивко да ги испечати полињата. Листа потпишана од друга CA, или застарена копија оставена во втора папка, не успева исто како истечена.

Генерирајте повторно од базата на отповикувања, не од нула

Новата листа мора да дојде од тековната база на отповикувања на CA, преку одобрениот процес на потпишување. Генерирањето празна листа, или повторното генерирање од стара резервна копија на индексот, тивко го укинува отповикувањето на секој идентитет додаден по таа копија. Тоа го претвора прекинот на најава во безбедносна регресија, и никој не го забележува затоа што симптомот исчезнува.

Држете го чекорот за генерирање под контрола на верзии заедно со останатите CA алатки, за да бидат интервалот и клучот за потпишување документирани, а не запаметени. Доволен е запис во runbook што ги именува командата, потписникот и целта на објавување. Тогаш секој што е на дежурство може повторно да генерира без да погодува која индексна датотека е меродавна. Чувајте го серискиот број на листата и времето на следното ажурирање со записот за распоредување.

Распоредете таму каде што гледа проверувачот

Копирајте ја новата листа на патеката што ја чита услугата, поставете сопственост и режим така што сервисната сметка може да ја чита, а другите не, и вчитајте повторно или рестартирајте според документираното однесување. Ако демонот ја кешира листата при стартување, замената на датотеката без повторно вчитување не менува ништо што работечкиот процес би го забележал. Потврдете го временскиот печат што процесот го пријавува по повторното вчитување.

Ако неколку услуги проверуваат клиенти, распоредете кај секоја од нив. Ажурирањето на една крајна точка и оставањето на друга со старата копија создава дефект што се појавува само кај корисниците што ќе слетаат на втората. Држете кратка листа на тие крајни точки во истиот runbook. По распоредувањето, проверете го пријавениот датум на листата за секоја од нив наместо да претпоставите дека копијата пристигнала.

Направете го следниот рок видлив пред да помине

Подолг интервал на објавување ја намалува зачестеноста на овој инцидент без да создаде процес. Изберете го интервалот според политиката на операторот, потоа поставете предупредување на полето за следно ажурирање на распоредената листа со доволно време за повторно генерирање и распоредување. Предупредете на распоредената копија, а не на домаќинот на CA, затоа што распоредената копија е таа што не успева.

По распоредувањето, проверете ги двете насоки: дозволениот корисник се поврзува, а познат отповикан идентитет се уште не успева. Втората проверка е таа што фаќа нецелосно повторно генерирање, и бара една команда против тест профил што го држите токму за таа цел.