Samotný CSR není registrace: co musí VPN CA ověřit

Žádost o podpis certifikátu nese veřejný klíč a požadovaný subjekt podepsaný odpovídajícím soukromým klíčem. Tento podpis dokazuje, že žadatel klíč vlastní. Nedokazuje, že žadatel má nárok na jméno, zařízení nebo roli VPN, o kterou žádá, a zacházet s ní, jako by to dokazovala, je přesně to, jak se z tiketu help desku stane přidělení přístupu.

Dva modely registrace stojí za srovnání podle toho, co svazují, ne podle toho, kterým protokolem mluví.

Žádost tvrdí jméno, ale nedokazuje ho

Čtěte žádost podle toho, co skutečně obsahuje: veřejný klíč, subjekt, který si žadatel zvolil, a vlastní podpis nad oběma. Nic v této struktuře neodkazuje na váš inventář, adresář účtů ani schvalovací postup. Subjekt cn=finance-laptop je řetězec, který někdo napsal. Dokud proces vydávání neověří tento řetězec proti záznamu, kterému důvěřuje, je certifikát tvrzení s připojeným podpisem. Tento rozdíl je celý důvod, proč proces registrace existuje.

Důsledek je provozně podstatný. Certifikační autorita nikdy nepotřebuje soukromý klíč klienta, aby vydala certifikát, a postup, který ho žádá, si plete podepisování s úschovou klíčů. Generování nechte na koncovém bodě a posílejte jen veřejnou polovinu.

Porovnejte modely podle toho, co svazují

Ruční podepisování svazuje to, co si operátor pamatuje, že má ověřit. Automatizovaná služba registrace svazuje ověřenou žádost s rozhodnutím, které služba umí vynutit, a RFC 7030 popisuje jeden takový návrh, kde se klient ověří, než je certifikát vrácen. Rozdíl, který přežije audit, není automatizace; je to, zda kontrola identity probíhá uvnitř cesty vydávání, nebo vedle ní.

Oba modely musí stále odpovědět na stejné tři otázky. Kdo žádá, na jakém zařízení či roli a na jak dlouho. Tiketovací systém, který odpovědi zaznamenává, dělá skutečnou práci; fronta, kde někdo zírá na obecné jméno, ne, ať je certifikát později naformátován jakkoli pečlivě.

Model vybírejte podle počtu registrací, které očekáváte, a podle obměny zařízení. Několik serverů ročně zvládne ruční revizi s psaným kontrolním seznamem. Park notebooků ne.

Zaznamenejte životní cyklus od prvního vydání

Uložte identifikátor certifikátu, vlastníka, zamýšlené použití, platnost a cestu odstranění v okamžiku vydání, ne při prvním incidentu. Zamýšlené použití patří do samotného certifikátu prostřednictvím rozšířeného použití klíče a záznam s ním musí souhlasit. Certifikát vytvořený pro ověřování klientů nesmí být nerozlišitelný od certifikátu pro server.

Naplánujte obnovu a odvolání ztraceného zařízení dřív, než vydáte desátý profil. Certifikát sdílený napříč oddělením mění cílené odstranění ve výpadek a toto rozhodnutí je mnohem levnější přezkoumat teď než během pátečního incidentu.

Ověřte vydaný certifikát a potom přístup

Po registraci prohlédněte, co bylo vydáno, a potvrďte, že řetězí k autoritě, kterou očekáváte. Dva příkazy pokrývají běžné chyby: certifikát se špatným použitím a řetěz, který funguje jen proto, že klient je nastaven ignorovat validaci.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Potom testujte přístup, ne artefakt. Certifikát stanoví identitu a politika stále rozhoduje, které služby tato identita smí dosáhnout. Zkontrolujte obojí, protože správný artefakt s příliš širokou politikou také neprojde revizí. Potvrďte, že se klient ověří a dostane jen zamýšlené trasy či zdroje. Zapište, co jste pozorovali, ne co měl profil dělat.

Profil, který funguje ze špatného důvodu, třeba shodné obecné jméno a žádná kontrola identity, bude fungovat dál i poté, co kontrolu, o níž jste si mysleli, že ji máte, někdo odstraní.