Fornye eit VPN-sertifikat utan å endre identiteten

Ei sertifikatfornying som endrar identiteten er ikkje ei fornying, det er ei migrering i vedlikehaldsbillettar. Klienten stadfestar eit namn, ei kjede og stundom ein bestemt nøkkel, og alle tre kan endrast utan at utløpsdatoen endrar seg. Skriv ned kva klienten faktisk sjekkar før du ber om ein erstatning: vertsnamnet eller peer-identiteten, føremålet med sertifikatet, nøkkelpolicyen og den utstedande kjeda. Fornyinga er rutine eller koordinert avhengig av kva av desse erstatninga endrar.

Tre vilkår avgjer forma på fornyinga

Dei tre vilkåra er om noko festar bladet, om kjeda endrar seg, og kven andre som validerer namnet. Svar frå klientsida i staden for frå komforten til CA-en, fordi klienten er det som sviktar klokka tre om natta.

Byrja med å inspisere sertifikatet du har. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName skriv ut subjektet, utstedaren, gyldigheitsvindauget og namna sertifikatet faktisk er gyldig for. Det siste feltet er det viktigaste og det som oftast vert føresett: ein fornyingsførespurnad som utelèt ein SAN klienten er avhengig av, gjev eit sertifikat som er teknisk gyldig og funksjonelt feil. Kopier SAN-lista frå det gamle sertifikatet inn i førespurnaden i staden for å skrive ho på nytt frå minnet.

Vilkår éin: festar noko bladet

Viss klientar stolar på ein vedlikehalden CA og validerer namnet, er ei bladfornying med ny nøkkel usynleg for dei. Viss ein klient festar bladsertifikatet, fingeravtrykket eller den offentlege nøkkelen, er erstatninga ei koordinert endring med eit hardt kutt, fordi den gamle festen ikkje kan validere det nye sertifikatet.

Finn ut kva tilfelle du er i før du bestiller noko. Ein fest som ingen dokumenterte, er framleis ein fest når han ryker.

Vilkår to: samanlikn festane og kjeda

Fingeravtrykk gjer festen kontrollerbar: openssl x509 -noout -fingerprint -sha256 -in server.crt på det gamle og det nye sertifikatet, og openssl x509 -noout -pubkey for å samanlikne offentlege nøklar. Viss klientkonfigurasjonen, ein mobilprofil eller ei tillitslagring på ein eining inneheld ein av verdiane, har du ein fest. Mobile VPN-profil er eit vanleg skjulestad, fordi profilen vert distribuert éin gong og aldri inspisert igjen.

Viss erstatninga kjem frå same mellomledd og klienten allereie har det mellomleddet eller kan hente det, endrar ingenting seg på tillitssida. Eit nytt mellomledd, ein annan utstedar eller ei kjede levert i feil rekkjefølgje gjer ei fornying til ei tillitsendring, og feilen ser ut som ein ukjend utstedar i staden for eit utløpt sertifikat.

Sjekk kjeda serveren faktisk sender med openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, og verifiser ho lokalt med openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Å gjere det før endringa gjev deg ein grunnlinje å samanlikne mot etterpå.

Vilkår tre: kven andre validerer namnet

Ein VPN-konsentrator, ein lastbalansar, ein overvakingsprobe, ein RADIUS- eller SAML-integrasjon og ein mobilprofil kan kvar halde si eiga kopi av det forventa namnet eller tillitsankeret. Fornyinga er augneblinken der desse kopiane sprikjer, fordi sertifikatet endrar seg og kopiane ikkje.

List opp kvar forbrukar før endringa og avgjer for kvar om han treng ein oppdatering. Den du gløymer, er den som varslar deg.

Det er også ei tidsfelle. Inspiser gyldigheitsstarten så vel som utløpet, fordi eit sertifikat som er klargjort for seinare aktivering vert avvist viss det vert installert for tidleg, og feilen ser ut som eit klokkeproblem i staden for eit klargjeringsproblem. openssl x509 -noout -dates på den nye fila før du distribuerer ho er ein sjekk på to sekund. Hald også ein støtta gjenopprettingsveg og den kjende gode konfigurasjonen, slik at ei fornying som går gale kan reverserast ved å gjenopprette det førre sertifikatet og nøkkelen.

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

Ein etablert tunnel speglar valideringa som skjedde då han vart bygd, så han kan sjå sunn ut medan kvar ny tilkopling sviktar. Test med ein fersk autentisering med det faktiske tenestenamnet klientane brukar.

Fullfør applikasjonsnivåkontrollen brukaren bryr seg om, og stadfest kjedeleveransen frå klienten sitt perspektiv i staden for serveren sitt. Ikkje undertrykk namne- eller sertifikatkontrollar for å halde overgangen stille; det gjer eit mellombels kompatibilitetsproblem permanent.

Trekk tilbake utdatert materiale først etter at utrullinga er verifisert, og handsam ein kompromittert nøkkel som ei heilt anna sak: fornying åleine tilbakekallar ingenting, så den råka identiteten treng tilbakekallings- og økthandsamingsprosessen til distribusjonen. RFC 5280 definerer sertifikat- og stivalideringsreglane som ligg under alt dette. Hald ei rutinemessig bladfornying skild frå ein CA-erstatning, slik at klientar ikkje vert bedne om å stole på ein ny utstedar utan grunn.