Forny et VPN-certifikat uden at ændre dets identitet

En certifikatfornyelse, der ændrer identiteten, er ikke en fornyelse, men en migrering i vedligeholdelsesbilletens klæder. Klienten verificerer et navn, en kæde og nogle gange en bestemt nøgle, og alle tre kan ændre sig, uden at udløbsdatoen ændrer sig. Skriv ned, hvad klienten faktisk kontrollerer, før du anmoder om en erstatning: værtsnavnet eller peer-identiteten, certifikatets formål, nøglepolitikken og den udstedende kæde. Fornyelsen er rutine eller koordineret, afhængigt af hvilke af disse erstatningen ændrer.

Tre betingelser afgør fornyelsens form

De tre betingelser er, om noget fastgør løvcertifikatet, om kæden ændres, og hvem der ellers validerer navnet. Svar ud fra klientsiden snarere end ud fra CA'ens bekvemmelighed, fordi klienten er det, der fejler klokken tre om natten.

Start med at inspicere det certifikat, du har. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName udskriver subjektet, udstederen, gyldighedsvinduet og de navne, som certifikatet faktisk er gyldigt for. Det sidste felt er det vigtigste og det mest antagne: en fornyelsesanmodning, der udelader et SAN, som klienten er afhængig af, giver et certifikat, der er teknisk gyldigt og funktionelt forkert. Kopiér SAN-listen fra det gamle certifikat til anmodningen i stedet for at skrive den igen fra hukommelsen.

Betingelse et: fastgør noget løvcertifikatet

Hvis klienterne stoler på en vedligeholdt CA og validerer navnet, er en fornyelse af løvcertifikatet med en ny nøgle usynlig for dem. Hvis en klient fastgør løvcertifikatet, dets fingeraftryk eller dets offentlige nøgle, er erstatningen en koordineret ændring med et hårdt skift, fordi den gamle pin ikke kan validere det nye certifikat.

Find ud af, hvilket tilfælde du er i, før du bestiller noget. En pin, som ingen har dokumenteret, er stadig en pin, når den brækker.

Betingelse to: sammenlign pins og kæde

Fingeraftryk gør pinnen kontrollerbar: openssl x509 -noout -fingerprint -sha256 -in server.crt på det gamle og det nye certifikat, og openssl x509 -noout -pubkey for at sammenligne offentlige nøgler. Hvis klientkonfigurationen, en mobilprofil eller et apparats trust store indeholder en af de to værdier, har du en pin. Mobile VPN-profiler er et almindeligt skjulested, fordi profilen distribueres én gang og aldrig inspiceres igen.

Hvis erstatningen kommer fra samme mellemcertifikat, og klienten allerede har det eller kan hente det, ændrer intet sig på tillidsiden. Et nyt mellemcertifikat, en anden udsteder eller en kæde leveret i forkert rækkefølge gør alle en fornyelse til en tillidsændring, og fejlen ligner en ukendt udsteder snarere end et udløbet certifikat.

Kontrollér den kæde, serveren faktisk sender, med openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, og verificér den lokalt med openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Det giver dig en baseline at sammenligne med bagefter, hvis du gør det før ændringen.

Betingelse tre: hvem ellers validerer navnet

En VPN-koncentrator, en load balancer, en overvågningsprobe, en RADIUS- eller SAML-integration og en mobilprofil kan hver især have deres egen kopi af det forventede navn eller tillidsankeret. Fornyelsen er det øjeblik, hvor disse kopier divergerer, fordi certifikatet ændrer sig, og kopierne gør ikke.

List hver forbruger op før ændringen, og beslut for hver, om den skal opdateres. Den, du glemmer, er den, der kalder på dig.

Der er også en tidsfælde. Inspicér gyldighedsstarten såvel som udløbet, fordi et certifikat, der er klargjort til senere aktivering, afvises, hvis det installeres for tidligt, og fejlen ligner et urproblem snarere end et klargøringsproblem. openssl x509 -noout -dates på den nye fil, før du udruller den, er et tjek på to sekunder. Hold også en understøttet gendannelsesvej og den kendte gode konfiguration, så en fornyelse, der går galt, kan rulles tilbage ved at gendanne det forrige certifikat og den forrige nøgle.

Udrul, verificér med en frisk godkendelse, og pensionér derefter

En etableret tunnel afspejler den validering, der fandt sted, da den blev oprettet, så den kan se sund ud, mens hver ny forbindelse fejler. Test med en frisk godkendelse ved at bruge det faktiske servicenavn, som klienterne bruger.

Fuldfør den applikationsniveaukontrol, som brugeren går op i, og bekræft kædeleveringen fra klientens perspektiv snarere end fra serverens. Undertryk ikke navne- eller certifikatkontroller for at holde overgangen stille; det gør et midlertidigt kompatibilitetsproblem til et permanent.

Pensionér kun forældet materiale, efter at udrulningen er verificeret, og behandl en kompromitteret nøgle som en helt anden sag: fornyelse alene tilbagekalder intet, så den berørte identitet har brug for udrulningens tilbagekaldelses- og sessionshåndteringsproces. RFC 5280 definerer certifikat- og stivalideringsreglerne under alt dette. Hold en rutinemæssig fornyelse af løvcertifikatet adskilt fra en CA-erstatning, så klienterne ikke bliver bedt om at stole på en ny udsteder uden grund.