Vad som händer när du byter ut en VPN-certifikatutfärdare

Att byta ut en VPN-certifikatutfärdare är inte ett filbyte. I samma stund som den nya CA:n signerar sitt första certifikat måste varje validator som fortfarande bara litar på den gamla fatta ett beslut, och värdar som aldrig får det nya ankaret fortsätter att avvisa goda parter. Jag har sett det gå fel åt båda hållen: gatewayen lärde sig den nya CA:n och klienterna gjorde det inte, så nya anslutningar misslyckades, medan tunnlar som redan var uppe blev kvar och fick avbrottet att se ut som ett routingproblem. Här är vad som ändras, i den ordning felen dyker upp.

Ett byte, två separata ändringar

En certifikatutfärdare är ett namn, en publik nyckel och den privata nyckel som signerar. Validatorer litar aldrig på CA:n i abstrakt mening. De litar på ett specifikt certifikat som redan ligger i ett förtroendelager, och de accepterar en utgivare bara om en kedja av signaturer når fram till den lagrade kopian. Att byta ut CA:n ändrar därför två saker som fallerar oberoende av varandra: vilka ankare som accepteras och vilka partidentiteter som utfärdades under dem.

De flesta VPN-installationer validerar i båda riktningarna. Klienten autentiserar gatewayens certifikat och gatewayen autentiserar klientens. En övergång som bara uppdaterar klientpaketet låter servern avvisa varje klient som fortfarande presenterar en identitet från den gamla CA:n, och det omvända är lika vanligt. Inventera först tvingandepunkterna: klienternas förtroendelager, gatewayens ca-fil, eventuell TLS-avslutande proxy framför den och den sond som kontrollerar slutpunkten utifrån.

Vad en validator kontrollerar, i ordning

Sökvägsvalidering klättrar från partens certifikat genom eventuella mellanled tills den når ett betrott ankare. I varje steg verifierar den signaturen, kontrollerar att varje certifikat ligger inom sin giltighetsperiod och bekräftar att grundläggande begränsningar och nyckelanvändning tillåter utgivaren att signera. Först då tittar applikationen på bladcertifikatet: subjektets alternativa namn måste täcka namnet som anropades, och den utökade nyckelanvändningen måste tillåta server- eller klientautentisering.

För att upprepa den genomgången offline pekar du -CAfile mot exakt det paket du ska rulla ut, inte mot systemlagret. Annars testar du värden, inte ändringen:

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

Det kommandot fungerar bara mot en enkel TLS-lyssnare som gatewayens HTTPS-administrationssida; OpenVPN:s kontrollkanal kommer före TLS, så s_client kan inte inspektera tunnelns handskakning.

Sökvägsbyggnadsreglerna bakom de felen finns i RFC 5280 avsnitt 6. De förklarar de fel som annars verkar godtyckliga: ett utgånget mellanled som ingen kom ihåg, ett certifikat vars nyckelanvändning förbjuder signering, eller en namnavgränsning som utesluter värden du testar.

Varför den gamla tunneln fortsätter att fungera

TLS och OpenVPN håller båda en etablerad session vid liv efter att handskakningen är klar. Ingenting validerar om partens certifikat per paket, så en klient som anslöt före ändringen fortsätter att släppa igenom trafik tills den förhandlar om, ansluter igen eller tunneln faller. Just detta gap gör att ett CA-byte kan se bra ut i en timme och sedan misslyckas i värsta möjliga stund: en bärbar dator vaknar ur viloläge, en NAT-mappning går ut, en gateway startar om.

Sessionsåterupptagning sträcker ut illusionen ännu mer. En TLS-sessionsbiljett låter klienten återvända utan att skicka certifikat igen, och återupptagningen hoppar över sökvägsvalidering eftersom den första handskakningen redan gjorde det. Det ärliga testet är därför en full handskakning i en ny process. Starta om klienten i stället för att återansluta tunneln, och överväg att stänga av biljetter på en testprofil så att återupptagningsvägen inte kan dölja en bruten kedja.

Håll det statiska nyckellagret åtskilt från detta. tls-auth lägger till en HMAC på kontrollkanalen, tls-crypt krypterar och autentiserar den, och ingen av dem bär certifikatmaterial, så rotation av någon av dem är en separat ändring med sitt eget felläge. Installationer som blandar de två slutar med en klient vars statiska nyckel är i ordning, vars certifikat är inaktuellt och vars felmeddelande inte nämner någon av dem.

Fällan med att återanvända subjektnamnet

Det är frestande att återanvända föregångarens distinkta namn så att ingenting nedströms behöver ändras. Det håller utgivarraden stabil i gränssnittet och förstör den enda signal du behöver. Två certifikat med identiska subjekt och olika nycklar går inte att skilja på namn, så ett paket med båda ankarna ger validatorn två kandidater och ingen regel för att välja.

Sökvägsbyggnaden kan då välja den felaktiga, rapportera att det lokala utgivarcertifikatet inte kan hämtas trots att rätt ankare finns, eller lyckas på en värd och misslyckas på en annan med samma paket, eftersom kandidaternas ordning skilde sig. Om namnet måste återanvändas, håll båda ankarna i separata filer under övergången och ladda dem explicit, och slå ihop dem först när varje part presenterar den nya utgivaren. Annars ge ersättningen ett eget vanligt namn — ett generations- eller datumsuffix räcker — så att loggar och feltexter säger under vilken myndighet en felande part utfärdades.

En rotation som inte tar ner nätet

Godta båda ankarna under ett begränsat fönster i stället för att byta i ett enda steg vid en planerad ersättning. Utfärda den nya CA:n och dess mellanled, lägg det nya ankaret i varje validators paket bredvid det gamla, och börja först därefter utfärda partcertifikat ur det. Parter med gamla identiteter valideras mot det gamla ankaret; nya fungerar mot det nya.

Gjort i den ordningen är varje steg reversibelt. Det fel du undviker är det samtidiga bytet, där en klient som missade paketuppdateringen möter en gateway som redan har pensionerat det gamla ankaret, handskakningen dör och ingen logg säger vilken sida som är inaktuell.

Dra tillbaka i motsatt riktning. Utfärda varje identitet på nytt som måste överleva, bekräfta att var och en presenterar den nya kedjan och ta sedan bort det gamla ankaret ur paketen. Ta den gamla CA:ns privata nyckel ur drift, för en utgivare som fortfarande kan signera betyder att rotationen inte är klar. Spara certifikaten och utfärdanderegistren för revision. En förlorad utgivare återställs till samma förtroende; en exponering kräver nya identiteter och ingen återgång till det gamla ankaret.

Verifiera resultatet, inte fillistan

En förtroendefil i förväntad katalog bevisar lite. Applikationen kan läsa en annan sökväg, ett annat format eller en kopia i ett paket som en uppgradering ersätter. Kontrollera beteendet i båda ändarna, inte att en fil finns.

Bekräfta att en ny anslutning med en ny identitet lyckas och bekräfta sedan att en identitet utfärdad av den pensionerade CA:n avvisas. Det andra testet är det folk hoppar över, och det enda som visar att den gamla myndigheten inte längre ger åtkomst. Där installationen bygger på CRL eller OCSP, kontrollera att distributionspunkterna i de nya certifikaten löses upp och att parterna som frågar når svararen.

Avsluta med en klient som aldrig har anslutit: rensa profilens tillstånd, anslut och läs den förhandlade kedjan. En part som återupptar en cachad session rapporterar glatt att migreringen lyckades utan att ha validerat något.