Co se stane, když vyměníte certifikační autoritu VPN

Vyměnit certifikační autoritu VPN není výměna souboru. Ve chvíli, kdy nová CA podepíše první certifikát, musí se každý validátor, který stále věří jen té staré, rozhodnout, a hostitelé, kteří novou kotvu nikdy nedostanou, dál odmítají dobré protějšky. Viděl jsem to selhat oběma směry: brána se naučila novou CA a klienti ne, takže nová spojení padala, zatímco už navázané tunely zůstaly a výpadek vypadal jako problém s routováním. Tady je, co se mění, v pořadí, v jakém se poruchy objevují.

Jedna výměna, dvě oddělené změny

Certifikační autorita je jméno, veřejný klíč a soukromý klíč, kterým se podepisuje. Validátory nikdy nevěří „CA“ jako takové. Věří jednomu konkrétnímu certifikátu, který už leží v úložišti důvěry, a vydavatele přijmou jen tehdy, když se řetězec podpisů dostane k této uložené kopii. Výměna CA proto mění dvě věci, které selhávají nezávisle: které kotvy se přijímají a které identity protějšků pod nimi byly vydány.

Většina nasazení VPN ověřuje oběma směry. Klient autentizuje certifikát brány a brána certifikát klienta. Výměna, která obnoví jen klientský balík, nechá server odmítat každého klienta, který stále předkládá identitu staré CA, a opačně je to stejně časté. Nejprve si zmapujte místa vynucení: úložiště důvěry klientů, soubor ca brány, jakoukoli proxy ukončující TLS před ní a sondu, která kontroluje koncový bod zvenčí.

Co validátor kontroluje, v pořadí

Validace cesty stoupá od certifikátu protějšku přes mezilehlé certifikáty, dokud nedojde k důvěryhodné kotvě. V každém kroku ověří podpis, zkontroluje, že každý certifikát leží v době platnosti, a potvrdí, že základní omezení a použití klíče vydavateli dovolují podepisovat. Teprve pak se aplikace podívá na koncový certifikát: alternativní jména subjektu musí pokrývat volané jméno a rozšířené použití klíče musí dovolovat autentizaci serveru nebo klienta.

Chcete-li ten průchod zopakovat offline, namiřte -CAfile na přesný balík, který budete nasazovat, a ne do systémového úložiště. Jinak testujete hostitele, ne změnu:

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

Tento příkaz funguje jen proti obyčejnému TLS listeneru, jako je HTTPS administrační stránka brány; řídicí kanál OpenVPN předchází TLS, takže s_client nedokáže prohlédnout handshake tunelu.

Pravidla sestavování cesty, která stojí za těmito chybami, jsou v RFC 5280 oddíl 6. Vysvětlují poruchy, které jinak vypadají svévolně: prošlý mezilehlý certifikát, na který si nikdo nevzpomněl, certifikát, jehož použití klíče podepisování zakazuje, nebo omezení jména, které vylučuje testovaného hostitele.

Proč starý tunel funguje dál

TLS i OpenVPN udržují navázanou relaci živou i po skončení handshake. Nic neověřuje certifikát protějšku u každého paketu, takže klient připojený před změnou dál propouští provoz, dokud znovu nevyjedná, nepřipojí se nebo tunel nespadne. Právě tato mezera způsobuje, že výměna CA může hodinu vypadat dobře a pak selhat v nejhorší chvíli: notebook se probudí ze spánku, mapování NAT vyprší, brána se restartuje.

Obnovení relace iluzi dál natahuje. Lístek relace TLS umožní klientovi vrátit se bez opětovného poslání certifikátů a obnovení přeskočí validaci cesty, protože první handshake ji už provedl. Poctivý test je proto plný handshake v novém procesu. Restartujte klienta, místo abyste znovu připojovali tunel, a na testovacím profilu zvažte vypnutí lístků, aby cesta obnovení nemohla skrýt rozbitý řetězec.

Vrstvu statického klíče držte od toho oddělenou. tls-auth přidává do řídicího kanálu HMAC, tls-crypt ho šifruje a autentizuje, a ani jedno nenese certifikátový materiál, takže rotace kteréhokoli z nich je samostatná změna s vlastním režimem selhání. Nasazení, která obojí smíchají, skončí s klientem, jehož statický klíč je v pořádku, certifikát zastaralý a chybová zpráva nezmiňuje ani jedno.

Past opětovného použití jména subjektu

Láká znovu použít rozlišující jméno předchůdce, aby se níž nic nemuselo měnit. To drží řádek vydavatele stabilní v rozhraní a ničí jediný signál, který potřebujete. Dva certifikáty se shodnými subjekty a různými klíči nelze podle jména rozeznat, takže balík s oběma kotvami dá validátorovi dva kandidáty a žádné pravidlo pro volbu.

Sestavování cesty pak může vybrat špatnou, hlásit „nelze získat certifikát místního vydavatele“, i když je správná kotva přítomná, nebo uspět na jednom hostiteli a selhat na jiném se stejným balíkem, protože se pořadí kandidátů lišilo. Musí-li se jméno opakovat, držte obě kotvy během přechodu v oddělených souborech a načítejte je výslovně, a slučte je teprve tehdy, až každý protějšek předloží nového vydavatele. Jinak dejte náhradě odlišné obecné jméno — přípona generace nebo data stačí — aby logy a chybové texty říkaly, pod jakou autoritou byl selhávající protějšek vydán.

Výměna, která nesundá síť

U plánované výměny přijímejte obě kotvy po omezené okno, místo abyste přepínali v jediném kroku. Vydajte novou CA a její mezilehlé certifikáty, vložte novou kotvu do balíku každého validátoru vedle staré a teprve potom začněte z ní vydávat certifikáty protějšků. Protějšky se starými identitami se validují proti staré kotvě; nové fungují proti nové.

Když se to udělá v tomto pořadí, každý krok je vratný. Porucha, které se vyhýbáte, je současné přepnutí, kdy klient, který minul aktualizaci balíku, potká bránu, jež už starou kotvu vyřadila, handshake umře a žádný log neřekne, která strana je zastaralá.

Vyřazujte opačným směrem. Znovu vydajte každou identitu, která musí přežít, potvrďte, že každá předkládá nový řetězec, a teprve pak odstraňte starou kotvu z balíků. Vyřaďte soukromý klíč staré CA z provozu, protože vydavatel, který ještě může podepisovat, znamená, že výměna není dokončená. Certifikáty a záznamy o vydávání uchovejte pro audit. Ztracený vydavatel se obnovuje ke stejné důvěře; prozrazení vyžaduje nové identity a žádný návrat ke staré kotvě.

Ověřte výsledek, ne seznam souborů

Soubor důvěry v očekávaném adresáři dokazuje málo. Aplikace může číst jinou cestu, jiný formát nebo kopii uvnitř balíčku, který upgrade nahradí. Kontrolujte chování na obou koncích, ne existenci souboru.

Potvrďte, že nové spojení s novou identitou uspěje, a pak potvrďte, že identita vydaná vyřazenou CA je odmítnuta. Druhý test lidé přeskakují a je jediný, který ukazuje, že stará autorita už nepovoluje přístup. Kde nasazení spoléhá na CRL nebo OCSP, zkontrolujte, že se distribuční body v nových certifikátech překládají a že respondér je dostupný z protějšků, které se ho ptají.

Skončete klientem, který se nikdy nepřipojil: vymažte stav jeho profilu, připojte se a přečtěte vyjednaný řetězec. Protějšek obnovující uloženou relaci ochotně oznámí, že migrace vyšla, i když nic neověřil.