Čo sa stane, keď vymeníte certifikačnú autoritu VPN

Vymeniť certifikačnú autoritu VPN nie je výmena súboru. V okamihu, keď nová CA podpíše svoj prvý certifikát, každý validátor, ktorý stále dôveruje len tej starej, sa musí rozhodnúť, a hostitelia, ktorí nikdy nedostanú novú kotvu, naďalej odmietajú dobrých partnerov. Videl som to zlyhať oboma smermi: brána sa naučila novú CA a klienti nie, takže nové spojenia zlyhávali, kým už nadviazané tunely zostali a poruchu vyzerali ako problém s routingom. Tu je, čo sa mení, v poradí, v akom sa poruchy objavujú.

Jedna výmena, dve oddelené zmeny

Certifikačná autorita je meno, verejný kľúč a súkromný kľúč, ktorý podpisuje. Validátory nikdy neveria „CA“ ako takej. Dôverujú jednému konkrétnemu certifikátu, ktorý už leží v úložisku dôvery, a vydavateľa prijmú len vtedy, keď sa reťazec podpisov dostane k tej uloženej kópii. Výmena CA preto mení dve veci, ktoré zlyhávajú nezávisle: ktoré kotvy sa prijímajú a ktoré identity partnerov pod nimi boli vydané.

Väčšina nasadení VPN overuje oboma smermi. Klient autentifikuje certifikát brány a brána certifikát klienta. Výmena, ktorá obnoví len klientsky balík, necháva server odmietať každého klienta, ktorý stále predkladá identitu starej CA, a opačne je to rovnako časté. Najprv zmapujte miesta vynucovania: úložiská dôvery klientov, súbor ca brány, akýkoľvek proxy ukončujúci TLS pred ňou a sondu, ktorá kontroluje koncový bod zvonku.

Čo validátor kontroluje, v poradí

Validácia cesty stúpa od certifikátu partnera cez medziľahlé certifikáty, až kým nedosiahne dôveryhodnú kotvu. V každom kroku overí podpis, skontroluje, že každý certifikát je v rámci platnosti, a potvrdí, že základné obmedzenia a použitie kľúča umožňujú vydavateľovi podpisovať. Až potom sa aplikácia pozrie na koncový certifikát: alternatívne názvy subjektu musia pokrývať volané meno a rozšírené použitie kľúča musí povoľovať autentifikáciu servera alebo klienta.

Ak chcete tento prechod zopakovať offline, nasmerujte -CAfile presne na balík, ktorý budete nasadzovať, a nie na systémové úložisko. Inak testujete hostiteľa, nie zmenu:

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 príkaz funguje len proti obyčajnému TLS poslucháčovi, ako je HTTPS administračná stránka brány; riadiaci kanál OpenVPN predchádza TLS, takže s_client nedokáže preskúmať podanie rúk tunela.

Pravidlá budovania cesty za týmito chybami sú v RFC 5280 časť 6. Vysvetľujú zlyhania, ktoré inak vyzerajú svojvoľne: vypršaný medziľahlý certifikát, na ktorý si nikto nespomenul, certifikát, ktorého použitie kľúča zakazuje podpisovanie, alebo obmedzenie mena, ktoré vylučuje testovaného hostiteľa.

Prečo starý tunel funguje ďalej

TLS aj OpenVPN udržiavajú nadviazanú reláciu nažive po skončení podania rúk. Nič znova neoveruje certifikát partnera pri každom pakete, takže klient pripojený pred zmenou ďalej prepúšťa prevádzku, kým znova nevyjedná, nepripojí sa alebo tunel nespadne. Práve táto medzera spôsobuje, že výmena CA môže hodinu vyzerať dobre a potom zlyhať v najhoršom okamihu: notebook sa zobudí zo spánku, mapovanie NAT vyprší, brána sa reštartuje.

Obnovenie relácie ilúziu ešte naťahuje. Lístok relácie TLS umožní klientovi vrátiť sa bez opätovného odoslania certifikátov a obnovenie preskočí validáciu cesty, pretože prvé podanie rúk ju už urobilo. Poctivý test je preto plné podanie rúk v novom procese. Reštartujte klienta namiesto opätovného pripojenia tunela a v testovacom profile zvážte vypnutie lístkov, aby cesta obnovenia nemohla skryť rozbitý reťazec.

Vrstvu statického kľúča držte od tohto oddelene. tls-auth pridáva do riadiaceho kanála HMAC, tls-crypt ho šifruje a autentifikuje a ani jedno nenesie certifikátový materiál, takže rotácia ktoréhokoľvek z nich je samostatná zmena s vlastným režimom zlyhania. Nasadenia, ktoré obe zmiešajú, skončia s klientom, ktorého statický kľúč je v poriadku, certifikát zastaraný a chybová správa nespomína ani jedno.

Pasca opätovného použitia mena subjektu

Láka znovu použiť rozlišovacie meno predchodcu, aby sa nič nižšie nemuselo meniť. To drží riadok vydavateľa stabilný v rozhraní a ničí jediný signál, ktorý potrebujete. Dva certifikáty s rovnakými subjektmi a rôznymi kľúčmi sa nedajú rozlíšiť podľa mena, takže balík s oboma kotvami dá validátorovi dvoch kandidátov a žiadne pravidlo výberu.

Budovanie cesty potom môže vybrať nesprávnu, hlásiť „nepodarilo sa získať certifikát miestneho vydavateľa“, hoci správna kotva je prítomná, alebo uspieť na jednom hostiteľovi a zlyhať na inom s rovnakým balíkom, pretože poradie kandidátov bolo iné. Ak sa meno musí opätovne použiť, držte obe kotvy počas prechodu v oddelených súboroch a načítajte ich explicitne a zlúčte ich až vtedy, keď každý partner predloží nového vydavateľa. Inak dajte náhrade odlišné všeobecné meno — prípona generácie alebo dátumu stačí — aby logy a texty chýb povedali, pod akou autoritou bol zlyhávajúci partner vydaný.

Rotácia, ktorá nezloží sieť

Pri plánovanej výmene prijímajte obe kotvy po obmedzený čas namiesto prepnutia v jednom kroku. Vydajte novú CA a jej medziľahlé certifikáty, vložte novú kotvu do balíka každého validátora vedľa starej a až potom začnite z nej vydávať certifikáty partnerov. Partneri so starými identitami sa validujú proti starej kotve; noví fungujú proti novej.

Vykonané v tomto poradí, každý krok je vratný. Zlyhanie, ktorému sa vyhýbate, je súčasné prepnutie, keď klient, ktorý zmeškal aktualizáciu balíka, stretne bránu, ktorá už starú kotvu vyradila, podanie rúk zomrie a žiadny log nepovie, ktorá strana je zastaraná.

Vyraďujte opačným smerom. Vydajte znova každú identitu, ktorá musí prežiť, potvrďte, že každá predkladá nový reťazec, a potom odstráňte starú kotvu z balíkov. Vyraďte zo služby súkromný kľúč starej CA, pretože vydavateľ, ktorý ešte môže podpisovať, znamená, že výmena nie je dokončená. Certifikáty a záznamy o vydávaní uchovajte pre audit. Strata vydavateľa sa obnovuje na tú istú dôveru; prezradenie vyžaduje nové identity a žiadny návrat k starej kotve.

Overte výsledok, nie zoznam súborov

Súbor dôvery v očakávanom adresári dokazuje málo. Aplikácia môže čítať inú cestu, iný formát alebo kópiu v balíku, ktorý aktualizácia nahradí. Kontrolujte správanie na oboch koncoch, nie existenciu súboru.

Potvrďte, že nové spojenie s novou identitou uspeje, a potom potvrďte, že identita vydaná vyradenou CA je odmietnutá. Práve ten druhý test ľudia vynechávajú a je jediný, ktorý ukazuje, že stará autorita už neudeľuje prístup. Kde sa nasadenie spolieha na CRL alebo OCSP, skontrolujte, či sa distribučné body v nových certifikátoch prekladajú a či partneri, ktoré sa pýtajú, dosiahnu na respondér.

Skončite klientom, ktorý sa nikdy nepripojil: vymažte stav jeho profilu, pripojte sa a prečítajte vyjednaný reťazec. Partner obnovujúci uloženú reláciu ochotne oznámi, že migrácia vyšla, hoci nič neoveril.