Obnavljanje VPN certifikata bez promjene njegovog identiteta

Obnavljanje certifikata koje mijenja identitet nije obnavljanje, to je migracija u odjeći zahtjeva za održavanje. Klijent provjerava ime, lanac i ponekad određeni ključ, a sva tri se mogu promijeniti bez promjene datuma isteka. Prije nego zatražite zamjenu, zapišite šta klijent zapravo provjerava: ime hosta ili identitet partnera, namjenu certifikata, politiku ključeva i lanac izdavanja. Obnavljanje je rutinsko ili koordinirano ovisno o tome šta od toga zamjena mijenja.

Tri uvjeta određuju oblik obnavljanja

Tri uvjeta su: da li nešto prikiva krajnji certifikat, mijenja li se lanac i ko još provjerava ime. Odgovorite na to sa strane klijenta, a ne iz udobnosti CA, jer klijent je ono što pada u tri sata ujutro.

Počnite pregledom certifikata koji imate. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ispisuje subjekt, izdavaoca, period valjanosti i imena za koja certifikat zapravo važi. Posljednje polje je najvažnije i najčešće se pretpostavlja: zahtjev za obnavljanje koji izostavi SAN na koji se klijent oslanja proizvodi certifikat koji je tehnički valjan i funkcionalno pogrešan. Kopirajte listu SAN iz starog certifikata u zahtjev umjesto da je ponovo kucate po sjećanju.

Uvjet jedan: prikiva li nešto krajnji certifikat

Ako klijenti vjeruju održavanom CA i provjeravaju ime, obnavljanje krajnjeg certifikata s novim ključem im je nevidljivo. Ako bilo koji klijent prikiva krajnji certifikat, njegov otisak ili njegov javni ključ, zamjena je koordinirana promjena s tvrdim prelazom, jer stari pin ne može validirati novi certifikat.

Utvrdite u kojem ste slučaju prije nego što bilo šta naručite. Pin koji niko nije dokumentirao ostaje pin kad se slomi.

Uvjet dva: uporedite pinove i lanac

Otisci čine pin provjerljivim: openssl x509 -noout -fingerprint -sha256 -in server.crt na starom i novom certifikatu, i openssl x509 -noout -pubkey za poređenje javnih ključeva. Ako konfiguracija klijenta, mobilni profil ili trust store uređaja sadrži bilo koju od te dvije vrijednosti, imate pin. Mobilni VPN profili su često skrivalište, jer se profil distribuira jednom i više se nikad ne pregleda.

Ako zamjena dolazi od istog posrednika i klijent ga već ima ili ga može dohvatiti, na strani povjerenja se ništa ne mijenja. Novi posrednik, drugi izdavalac ili lanac dostavljen u pogrešnom redoslijedu pretvaraju obnavljanje u promjenu povjerenja, a kvar izgleda kao nepoznat izdavalac, a ne kao istekao certifikat.

Provjerite lanac koji server zaista šalje pomoću openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, i provjerite ga lokalno pomoću openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Ako to uradite prije promjene, imate osnovu za poređenje poslije.

Uvjet tri: ko još provjerava ime

VPN koncentrator, balanser opterećenja, monitorinška sonda, RADIUS ili SAML integracija i mobilni profil svaki mogu držati vlastitu kopiju očekivanog imena ili sidra povjerenja. Obnavljanje je trenutak kada se te kopije razilaze, jer certifikat se mijenja, a kopije ne.

Navedite svakog potrošača prije promjene i odlučite za svakog treba li mu ažuriranje. Onaj koga zaboravite je onaj koji vas poziva.

Postoji i vremenska zamka. Pregledajte početak valjanosti kao i datum isteka, jer certifikat pripremljen za kasniju aktivaciju biva odbijen ako se instalira prerano, a greška izgleda kao problem sa satom, a ne kao problem s pripremom. openssl x509 -noout -dates na novoj datoteci prije postavljanja je provjera od dvije sekunde. Držite i podržan put oporavka i poznatu ispravnu konfiguraciju, da obnavljanje koje pođe po zlu bude reverzibilno vraćanjem prethodnog certifikata i ključa.

Postavite, provjerite svježom autentifikacijom, pa povucite

Uspostavljeni tunel odražava validaciju koja se dogodila pri njegovom postavljanju, pa može izgledati zdravo dok svaka nova veza pada. Testirajte svježom autentifikacijom koristeći stvarno ime usluge koje klijenti koriste.

Dovršite provjeru na razini aplikacije koja je korisniku važna i potvrdite dostavu lanca iz perspektive klijenta, a ne servera. Ne potiskujte provjere imena ili certifikata da tranzicija prođe tiho; to pretvara privremeni problem kompatibilnosti u trajni.

Povucite zastarjeli materijal tek nakon što je uvođenje provjereno, a kompromitirani ključ tretirajte kao potpuno drugi slučaj: obnavljanje samo po sebi ništa ne opoziva, pa zahvaćeni identitet treba proces opoziva i upravljanja sesijama uvođenja. RFC 5280 definiše pravila certifikata i validacije puta na kojima sve ovo počiva. Držite rutinsko obnavljanje krajnjeg certifikata odvojeno od zamjene CA, da se od klijenata ne traži da vjeruju novom izdavaocu bez razloga.