Новите VPN влизания се провалят, докато сертификатите са валидни: проверете CRL

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

Разделянето на двата графика е цялата диагноза и то променя какво трябва да бъде решението.

Два часовника и само един от тях е сертификатът

Сертификатът носи прозорец на валидност. Списъкът за оттегляне на сертификати носи собствен прозорец, плюс издател и подпис, и проверяващите отказват да се доверят на списък, чието време за следващо обновяване е изтекло. Когато това се случи, клиентът представя напълно валиден сертификат и сървърът все пак прекъсва връзката със съобщение за списъка. Потребителите четат това съобщение като 'сертификатът е изтекъл', което изпраща заявката за подновяване на грешното място.

Двата обекта имат и различни собственици: сертификатът идва от 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, защото внедреното копие е това, което се проваля.

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