Подновяване на VPN сертификат без промяна на самоличността му

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

Три условия определят формата на подновяването

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

Започнете с преглед на сертификата, който имате. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName отпечатва субекта, издателя, периода на валидност и имената, за които сертификатът всъщност е валиден. Последното поле е най-важно и най-често се предполага: заявка за подновяване, която пропуска SAN, на който клиентът разчита, създава сертификат, технически валиден и функционално грешен. Копирайте списъка със SAN от стария сертификат в заявката, вместо да го преписвате по памет.

Първо условие: фиксира ли нещо крайния сертификат

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

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

Второ условие: сравнете фиксиранията и веригата

Отпечатъците правят фиксирането проверимо: openssl x509 -noout -fingerprint -sha256 -in server.crt на стария и новия сертификат, и openssl x509 -noout -pubkey за сравняване на публичните ключове. Ако конфигурацията на клиента, мобилен профил или хранилище за доверие на устройство съдържа някоя от двете стойности, имате фиксиране. Мобилните VPN профили са често скривалище, защото профилът се разпространява веднъж и повече не се преглежда.

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

Проверете веригата, която сървърът всъщност изпраща, с openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, и я проверете локално с openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Правенето на това преди промяната ви дава базова линия за сравнение след нея.

Трето условие: кой друг проверява името

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

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

Има и капан във времето. Прегледайте началото на валидността, както и датата на изтичане, защото сертификат, подготвен за по-късно активиране, се отхвърля, ако бъде инсталиран твърде рано, и грешката изглежда като проблем с часовника, а не като проблем с подготовката. openssl x509 -noout -dates на новия файл преди разгръщането е проверка за две секунди. Пазете и поддържан път за възстановяване и известно-добра конфигурация, така че подновяване, което се обърка, да е обратимо чрез възстановяване на предишния сертификат и ключ.

Разгърнете, проверете с нова автентикация, след което изведете от употреба

Установеният тунел отразява валидацията, извършена при изграждането му, затова може да изглежда здрав, докато всяка нова връзка се проваля. Тествайте с нова автентикация, използвайки действителното име на услугата, което клиентите използват.

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

Извеждайте остарелите материали от употреба само след като разгръщането е проверено, и третирайте компрометирания ключ като напълно отделен случай: подновяването само по себе си не отменя нищо, затова засегнатата самоличност се нуждае от процеса на отменяне и управление на сесиите на разгръщането. RFC 5280 дефинира правилата за сертификати и валидиране на път, върху които стои всичко това. Дръжте рутинното подновяване на крайния сертификат отделно от замяната на CA, за да не се иска от клиентите да се доверяват на нов издател без причина.