Förnya ett VPN-certifikat utan att ändra dess identitet

En certifikatförnyelse som ändrar identiteten är inte en förnyelse, det är en migrering i underhållsbiljetter. Klienten verifierar ett namn, en kedja och ibland en specifik nyckel, och alla tre kan ändras utan att utgångsdatumet ändras. Innan du begär en ersättning, skriv ner vad klienten faktiskt kontrollerar: värdnamnet eller peer-identiteten, certifikatets syfte, nyckelprincipen och den utfärdande kedjan. Förnyelsen är rutin eller samordnad beroende på vilket av dessa ersättningen ändrar.

Tre villkor avgör förnyelsens form

De tre villkoren är om något fäster bladet, om kedjan ändras och vem mer som validerar namnet. Svara från klientsidan i stället för från CA:ns bekvämlighet, eftersom klienten är det som misslyckas klockan tre på natten.

Börja med att inspektera certifikatet du har. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName skriver ut subjektet, utfärdaren, giltighetsfönstret och namnen som certifikatet faktiskt är giltigt för. Det sista fältet är viktigast och tas oftast för givet: en förnyelsebegäran som utelämnar ett SAN som klienten förlitar sig på ger ett certifikat som är tekniskt giltigt men funktionellt fel. Kopiera SAN-listan från det gamla certifikatet till begäran i stället för att skriva den igen ur minnet.

Villkor ett: fäster något bladet

Om klienter litar på en underhållen CA och validerar namnet är en bladförnyelse med ny nyckel osynlig för dem. Om någon klient fäster bladcertifikatet, dess fingeravtryck eller dess offentliga nyckel är ersättningen en samordnad ändring med ett hårt byte, eftersom den gamla fästningen inte kan validera det nya certifikatet.

Ta reda på vilket fall du är i innan du beställer något. En fästning som ingen dokumenterat är fortfarande en fästning när den brister.

Villkor två: jämför fästningarna och kedjan

Fingeravtryck gör fästningen kontrollerbar: openssl x509 -noout -fingerprint -sha256 -in server.crt på det gamla och det nya certifikatet, och openssl x509 -noout -pubkey för att jämföra offentliga nycklar. Om klientkonfigurationen, en mobilprofil eller ett förtroendelager på en apparat innehåller något av värdena har du en fästning. Mobila VPN-profiler är ett vanligt gömställe, eftersom profilen distribueras en gång och aldrig inspekteras igen.

Om ersättningen kommer från samma mellanliggande och klienten redan har den eller kan hämta den ändras ingenting på förtroendesidan. En ny mellanliggande, en annan utfärdare eller en kedja som levereras i fel ordning gör en förnyelse till en förtroendeändring, och felet ser ut som en okänd utfärdare i stället för ett utgånget certifikat.

Kontrollera kedjan som servern faktiskt skickar med openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, och verifiera den lokalt med openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Att göra det före ändringen ger dig en baslinje att jämföra mot efteråt.

Villkor tre: vem mer validerar namnet

En VPN-koncentrator, en lastbalanserare, en övervakningsprob, en RADIUS- eller SAML-integration och en mobilprofil kan var och en hålla sin egen kopia av det förväntade namnet eller förtroendeankaret. Förnyelsen är ögonblicket då dessa kopior går isär, eftersom certifikatet ändras och kopiorna inte.

Lista varje konsument före ändringen och avgör för var och en om den behöver en uppdatering. Den du glömmer är den som larmar dig.

Det finns också en tidsfälla. Inspektera giltighetens början liksom utgången, eftersom ett certifikat som förberetts för senare aktivering avvisas om det installeras för tidigt, och felet ser ut som ett klockproblem i stället för ett förberedelseproblem. openssl x509 -noout -dates på den nya filen innan du distribuerar den är en kontroll på två sekunder. Behåll också en stödd återställningsväg och den kända goda konfigurationen, så att en förnyelse som går fel kan återställas genom att återställa det tidigare certifikatet och nyckeln.

Distribuera, verifiera med en färsk autentisering och dra sedan tillbaka

En etablerad tunnel återspeglar valideringen som skedde när den byggdes, så den kan se frisk ut medan varje ny anslutning misslyckas. Testa med en färsk autentisering med det faktiska tjänstenamnet som klienterna använder.

Slutför kontrollen på programnivå som användaren bryr sig om, och bekräfta kedjeleveransen ur klientens perspektiv i stället för serverns. Undertryck inte namn- eller certifikatkontroller för att hålla övergången tyst; det gör ett tillfälligt kompatibilitetsproblem permanent.

Dra tillbaka föråldrat material först efter att distributionen verifierats, och behandla en komprometterad nyckel som ett helt annat fall: förnyelse ensam återkallar ingenting, så den berörda identiteten behöver distributionens återkallnings- och sessionshanteringsprocess. RFC 5280 definierar certifikat- och sökvägsvalideringsreglerna som ligger under allt detta. Håll en rutinmässig bladförnyelse åtskild från en CA-ersättning, så att klienterna inte ombeds lita på en ny utfärdare utan anledning.