Fornye et VPN-sertifikat uten å endre identiteten

En sertifikatfornyelse som endrer identiteten er ikke en fornyelse, det er en migrering i vedlikeholdsbilletter. Klienten verifiserer et navn, en kjede og noen ganger en bestemt nøkkel, og alle tre kan endres uten at utløpsdatoen endres. Før du ber om en erstatning, skriv ned hva klienten faktisk sjekker: vertsnavnet eller peer-identiteten, sertifikatets formål, nøkkelpolicyen og den utstedende kjeden. Fornyelsen er rutine eller koordinert avhengig av hvilke av disse erstatningen endrer.

Tre vilkår avgjør fornyelsens form

De tre vilkårene er om noe fester bladet, om kjeden endres, og hvem andre som validerer navnet. Svar fra klientsiden i stedet for fra CA-ens bekvemmelighet, fordi klienten er det som feiler klokken tre om natten.

Start med å inspisere sertifikatet du har. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName skriver ut subjektet, utstederen, gyldighetsvinduet og navnene sertifikatet faktisk er gyldig for. Det siste feltet er det viktigste og det som oftest forutsettes: en fornyelsesforespørsel som utelater en SAN klienten er avhengig av, gir et sertifikat som er teknisk gyldig og funksjonelt feil. Kopier SAN-listen fra det gamle sertifikatet inn i forespørselen i stedet for å skrive den på nytt fra hukommelsen.

Vilkår én: fester noe bladet

Hvis klienter stoler på en vedlikeholdt CA og validerer navnet, er en bladfornyelse med ny nøkkel usynlig for dem. Hvis noen klient fester bladsertifikatet, fingeravtrykket eller den offentlige nøkkelen, er erstatningen en koordinert endring med et hardt kutt, fordi den gamle festen ikke kan validere det nye sertifikatet.

Finn ut hvilket tilfelle du er i før du bestiller noe. En fest som ingen dokumenterte, er fortsatt en fest når den ryker.

Vilkår to: sammenlign festene og kjeden

Fingeravtrykk gjør festen kontrollerbar: openssl x509 -noout -fingerprint -sha256 -in server.crt på det gamle og det nye sertifikatet, og openssl x509 -noout -pubkey for å sammenligne offentlige nøkler. Hvis klientkonfigurasjonen, en mobilprofil eller en tillitslagring på et apparat inneholder en av verdiene, har du en fest. Mobile VPN-profiler er et vanlig skjulested, fordi profilen distribueres én gang og aldri inspiseres igjen.

Hvis erstatningen kommer fra samme mellomledd og klienten allerede har det mellomleddet eller kan hente det, endres ingenting på tillitssiden. Et nytt mellomledd, en annen utsteder eller en kjede levert i feil rekkefølge gjør en fornyelse til en tillitsendring, og feilen ser ut som en ukjent utsteder i stedet for et utløpt sertifikat.

Sjekk kjeden serveren faktisk sender med openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, og verifiser den lokalt med openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Å gjøre det før endringen gir deg en baseline å sammenligne mot etterpå.

Vilkår tre: hvem andre validerer navnet

En VPN-konsentrator, en lastbalanserer, en overvåkingsprobe, en RADIUS- eller SAML-integrasjon og en mobilprofil kan hver holde sin egen kopi av det forventede navnet eller tillitsankeret. Fornyelsen er øyeblikket der disse kopiene spriker, fordi sertifikatet endres og kopiene ikke.

List opp hver forbruker før endringen og avgjør for hver om den trenger en oppdatering. Den du glemmer, er den som varsler deg.

Det er også en tidsfelle. Inspiser gyldighetsstarten så vel som utløpet, fordi et sertifikat som er klargjort for senere aktivering avvises hvis det installeres for tidlig, og feilen ser ut som et klokkeproblem i stedet for et klargjøringsproblem. openssl x509 -noout -dates på den nye filen før du distribuerer den er en sjekk på to sekunder. Hold også en støttet gjenopprettingsvei og den kjente gode konfigurasjonen, slik at en fornyelse som går galt kan reverseres ved å gjenopprette det forrige sertifikatet og nøkkelen.

Distribuer, verifiser med en fersk autentisering, og trekk deretter tilbake

En etablert tunnel gjenspeiler valideringen som skjedde da den ble bygget, så den kan se sunn ut mens hver ny tilkobling feiler. Test med en fersk autentisering med det faktiske tjenestenavnet klientene bruker.

Fullfør applikasjonsnivåkontrollen brukeren bryr seg om, og bekreft kjedeleveransen fra klientens perspektiv i stedet for serverens. Ikke undertrykk navne- eller sertifikatkontroller for å holde overgangen stille; det gjør et midlertidig kompatibilitetsproblem permanent.

Trekk tilbake utdatert materiale først etter at utrullingen er verifisert, og behandle en kompromittert nøkkel som en helt annen sak: fornyelse alene tilbakekaller ingenting, så den berørte identiteten trenger distribusjonens tilbakekallings- og øktbehandlingsprosess. RFC 5280 definerer sertifikat- og stivalideringsreglene som ligger under alt dette. Hold en rutinemessig bladfornyelse atskilt fra en CA-erstatning, slik at klienter ikke bes om å stole på en ny utsteder uten grunn.