Obnova VPN certifikata bez promjene identiteta

Obnova certifikata koja mijenja identitet nije obnova, to je migracija u odjeći radnog naloga za održavanje. Klijent provjerava ime, lanac i ponekad određeni ključ, a sve troje može se promijeniti bez promjene datuma isteka. Prije nego zatražite zamjenu, zapišite što klijent stvarno provjerava: naziv hosta ili identitet partnera, namjenu certifikata, pravila ključeva i lanac izdavatelja. Obnova je rutinska ili usklađena ovisno o tome što od toga zamjena mijenja.

Tri uvjeta odlučuju oblik obnove

Tri su uvjeta: fiksira li bilo što list, mijenja li se lanac i tko još provjerava ime. Odgovorite na njih sa strane klijenta, a ne po udobnosti CA, jer klijent je ono što zakaže u tri sata ujutro.

Počnite pregledom certifikata koji imate. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ispisuje subjekt, izdavatelja, razdoblje valjanosti i imena za koja je certifikat doista valjan. To posljednje polje najvažnije je i najčešće se pretpostavlja: zahtjev za obnovu koji izostavi SAN na koji se klijent oslanja daje certifikat koji je tehnički valjan, ali funkcionalno pogrešan. Kopirajte popis SAN iz starog certifikata u zahtjev umjesto da ga ponovno tipkate po sjećanju.

Uvjet jedan: fiksira li bilo što list

Ako klijenti vjeruju održavanom CA i provjeravaju ime, obnova lista s novim ključem za njih je nevidljiva. Ako bilo koji klijent fiksira certifikat lista, njegov otisak ili njegov javni ključ, zamjena je usklađena promjena s tvrdim prijelazom, jer stari pin ne može potvrditi novi certifikat.

Saznajte u kojem ste slučaju prije nego što bilo što naručite. Pin koji nitko nije dokumentirao i dalje je pin kad pukne.

Uvjet dva: usporedite pinove i lanac

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

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

Provjerite lanac koji poslužitelj stvarno šalje s openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts i potvrdite ga lokalno s openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Ako to učinite prije promjene, imat ćete osnovu za usporedbu poslije.

Uvjet tri: tko još provjerava ime

VPN koncentrator, balanser opterećenja, monitor za nadzor, RADIUS ili SAML integracija i mobilni profil svaki mogu držati vlastitu kopiju očekivanog imena ili sidra povjerenja. Obnova je trenutak u kojem se te kopije razilaze, jer se certifikat mijenja, a kopije ne.

Navedite svakog potrošača prije promjene i odlučite za svakoga treba li mu ažuriranje. Onaj koji zaboravite jest onaj koji će vas pozvati.

Postoji i vremenska zamka. Provjerite početak valjanosti kao i istek, jer se certifikat pripremljen za kasniju aktivaciju odbija ako se instalira prerano, a pogreška izgleda kao problem sa satom, a ne kao problem s pripremom. openssl x509 -noout -dates na novoj datoteci prije implementacije dvosekundna je provjera. Održavajte i podržani put oporavka i poznatu dobru konfiguraciju, kako bi se obnova koja pođe po zlu mogla poništiti vraćanjem prethodnog certifikata i ključa.

Implementirajte, potvrdite svježom autentifikacijom, zatim povucite

Uspostavljeni tunel odražava provjeru koja se dogodila kad je bio izgrađen, pa može izgledati zdravo dok svaka nova veza ne uspijeva. Testirajte svježom autentifikacijom koristeći stvarni naziv usluge koji klijenti koriste.

Dovršite provjeru na razini aplikacije do koje je korisniku stalo i potvrdite dostavu lanca iz perspektive klijenta, a ne poslužitelja. Ne potiskujte provjere imena ili certifikata da bi prijelaz bio tih; to privremeni problem kompatibilnosti pretvara u trajni.

Povucite zastarjeli materijal tek nakon što je implementacija potvrđena, a kompromitirani ključ tretirajte kao posve drugi slučaj: sama obnova ništa ne opoziva, pa pogođeni identitet treba proces opoziva i upravljanja sesijama te implementacije. RFC 5280 definira pravila certifikata i provjere putanje ispod svega ovoga. Držite rutinsku obnovu lista odvojenom od zamjene CA, kako se od klijenata ne bi tražilo da bez razloga vjeruju novom izdavatelju.