Какво се случва, когато смените сертифициращия орган на VPN

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

Една подмяна, две отделни промени

Сертифициращият орган е име, публичен ключ и частният ключ, който подписва. Валидаторите никога не се доверяват на „CA“ в абстрактен смисъл. Те се доверяват на конкретен сертификат, който вече стои в хранилище за доверие, и приемат издател само ако верига от подписи стигне до това запазено копие. Затова подмяната на CA променя две неща, които се провалят независимо: кои котви се приемат и кои самоличности на партньори са издадени под тях.

Повечето VPN внедрявания валидират и в двете посоки. Клиентът удостоверява сертификата на шлюза, а шлюзът — сертификата на клиента. Подмяна, която обновява само клиентския пакет, оставя сървъра да отхвърля всеки клиент, който още представя самоличност от стария CA, а обратното е също толкова често. Първо опишете точките на прилагане: хранилищата за доверие на клиентите, файла ca на шлюза, всеки прокси с TLS завършване пред него и проверката, която тества крайната точка отвън.

Какво проверява валидаторът, по ред

Проверката на пътя се изкачва от сертификата на партньора през междинните, докато стигне до надеждна котва. На всяка стъпка тя проверява подписа, следи всеки сертификат да е в срока си на валидност и потвърждава, че базовите ограничения и употребата на ключа позволяват на издателя да подписва. Едва тогава приложението поглежда крайния сертификат: алтернативните имена на субекта трябва да покриват набраното име, а разширената употреба на ключа да разрешава удостоверяване на сървър или клиент.

За да повторите това обхождане офлайн, насочете -CAfile към точния пакет, който ще внедрите, а не към системното хранилище. Иначе тествате хоста, не промяната:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Тази команда работи само срещу обикновен TLS слушател като администраторската HTTPS страница на шлюза; контролният канал на OpenVPN предхожда TLS, затова s_client не може да инспектира ръкостискането на тунела.

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

Защо старият тунел продължава да работи

TLS и OpenVPN поддържат установена сесия жива, след като ръкостискането приключи. Нищо не проверява отново сертификата на партньора за всеки пакет, затова клиент, свързан преди промяната, продължава да прекарва трафик, докато не предоговори, не се свърже отново или тунелът не падне. Точно тази пролука прави така, че подмяната на CA да изглежда наред в продължение на час и после да се провали в най-лошия момент: лаптоп се събужда от сън, NAT преобразуването изтича, шлюз се рестартира.

Възобновяването на сесията разтяга илюзията още. Билет за TLS сесия позволява на клиента да се върне без повторно изпращане на сертификати, а възобновяването прескача проверката на пътя, защото първото ръкостискане вече я е направило. Затова честният тест е пълно ръкостискане в нов процес. Рестартирайте клиента, вместо да свързвате тунела отново, и на тестов профил обмислете изключване на билетите, за да не може пътят на възобновяване да скрие счупена верига.

Дръжте слоя със статичния ключ отделно от това. tls-auth добавя HMAC към контролния канал, tls-crypt го криптира и удостоверява, и нито едно от двете не носи сертификатен материал, затова ротацията на което и да е е отделна промяна със собствен режим на отказ. Внедряванията, които смесват двете, получават клиент с наред статичен ключ, остарял сертификат и съобщение за грешка, което не споменава нито едното.

Капанът на повторната употреба на името на субекта

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

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

Промяна, която не сваля мрежата

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

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

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

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

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

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

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