Obnovení certifikátu VPN bez změny jeho identity

Obnovení certifikátu, které mění identitu, není obnovení, ale migrace převlečená za lístek údržby. Klient ověřuje název, řetěz a někdy konkrétní klíč a všechny tři se mohou změnit, aniž by se změnilo datum vypršení. Než požádáte o náhradu, zapište si, co klient skutečně kontroluje: název hostitele nebo identitu protistrany, účel certifikátu, politiku klíčů a vydávající řetěz. Obnovení je rutinní nebo koordinované podle toho, co z toho náhrada mění.

Tvar obnovení určují tři podmínky

Ty tři podmínky jsou: zda něco připíná koncový certifikát, zda se mění řetěz a kdo další ověřuje název. Odpovídejte na ně ze strany klienta, ne z pohodlí CA, protože klient je to, co ve tři ráno selhává.

Začněte prohlédnutím certifikátu, který máte. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName vypíše subjekt, vydavatele, období platnosti a názvy, pro které je certifikát skutečně platný. Poslední pole je nejdůležitější a nejčastěji se předpokládá: žádost o obnovení, která vynechá SAN, na který se klient spoléhá, vytvoří certifikát technicky platný a funkčně špatný. Zkopírujte seznam SAN ze starého certifikátu do žádosti, místo abyste ho přepisovali z paměti.

Podmínka jedna: připíná něco koncový certifikát

Pokud klienti důvěřují udržované CA a ověřují název, je obnovení koncového certifikátu s novým klíčem pro ně neviditelné. Pokud jakýkoli klient připíná koncový certifikát, jeho otisk nebo jeho veřejný klíč, je náhrada koordinovanou změnou s tvrdým přechodem, protože starý pin nedokáže ověřit nový certifikát.

Zjistěte, v jakém případě jste, než něco objednáte. Pin, který nikdo nedokumentoval, zůstává pinem, když se zlomí.

Podmínka dva: porovnejte piny a řetěz

Otisky činí pin ověřitelným: openssl x509 -noout -fingerprint -sha256 -in server.crt na starém a novém certifikátu a openssl x509 -noout -pubkey pro porovnání veřejných klíčů. Pokud konfigurace klienta, mobilní profil nebo úložiště důvěry zařízení obsahuje kteroukoli z těchto dvou hodnot, máte pin. Mobilní profily VPN jsou častým úkrytem, protože profil se distribuuje jednou a už se nikdy neprohlíží.

Pokud náhrada pochází ze stejného zprostředkujícího certifikátu a klient ho už má nebo si ho může stáhnout, na straně důvěry se nic nemění. Nový zprostředkující certifikát, jiný vydavatel nebo řetěz doručený ve špatném pořadí promění obnovení ve změnu důvěry a selhání vypadá jako neznámý vydavatel, ne jako vypršelý certifikát.

Zkontrolujte řetěz, který server skutečně posílá, pomocí openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts a ověřte ho lokálně pomocí openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Pokud to uděláte před změnou, získáte základ, se kterým lze později porovnávat.

Podmínka tři: kdo další ověřuje název

VPN koncentrátor, vyvažovač zátěže, monitorovací sonda, integrace RADIUS nebo SAML a mobilní profil mohou každý držet vlastní kopii očekávaného názvu nebo kořene důvěry. Obnovení je okamžik, kdy se tyto kopie rozejdou, protože certifikát se mění a kopie ne.

Před změnou vypište každého spotřebitele a u každého rozhodněte, zda potřebuje aktualizaci. Ten, na který zapomenete, je ten, který vás bude volat.

Je tu také časová past. Prohlédněte počátek platnosti stejně jako datum vypršení, protože certifikát připravený k pozdější aktivaci je odmítnut, pokud se nainstaluje příliš brzy, a chyba vypadá jako problém s hodinami, ne jako problém s přípravou. openssl x509 -noout -dates na novém souboru před nasazením je kontrola na dvě sekundy. Uchovejte si také podporovanou cestu obnovy a známou dobrou konfiguraci, aby šlo neúspěšné obnovení vrátit obnovením předchozího certifikátu a klíče.

Nasaďte, ověřte čerstvou autentizací a poté vyřaďte

Zavedený tunel odráží validaci, která proběhla při jeho sestavení, takže může vypadat zdravě, zatímco každé nové připojení selhává. Otestujte čerstvou autentizací pomocí skutečného názvu služby, který klienti používají.

Dokončete kontrolu na úrovni aplikace, na které uživateli záleží, a potvrďte doručení řetězu z pohledu klienta, ne serveru. Nepotlačujte kontroly názvu ani certifikátu, aby přechod proběhl tiše; tím přeměníte dočasný problém s kompatibilitou na trvalý.

Vyřaďte zastaralý materiál až po ověření nasazení a kompromitovaný klíč berte jako zcela jiný případ: samotné obnovení nic neodvolá, takže postižená identita potřebuje proces odvolání a správy relací daného nasazení. RFC 5280 definuje pravidla pro certifikáty a ověřování cesty, na kterých to všechno stojí. Držte rutinní obnovení koncového certifikátu oddělené od nahrazení CA, aby se po klientech nechtělo důvěřovat novému vydavateli bez důvodu.