Шта се дешава када замените издаваоца сертификата за 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, проверите да се тачке дистрибуције у новим сертификатима разрешавају и да партнери који питају достижу одговарача.

Завршите клијентом који се никада није повезао: обришите стање његовог профила, повежите се и прочитајте договорени ланац. Партнер који наставља кеширану сесију весело ће пријавити да је миграција успела, иако није валидирао ништа.