Samotný CSR ešte nie je registrácia: čo musí VPN CA overiť

Žiadosť o podpis certifikátu nesie verejný kľúč a požadovaný subject podpísaný zodpovedajúcim súkromným kľúčom. Tento podpis dokazuje, že žiadateľ má kľúč. Nedokazuje, že žiadateľ má právo na požadované meno, zariadenie alebo rolu vo VPN, a zaobchádzať so žiadosťou, akoby to dokazovala, je práve to, ako sa tiket na help desk zmení na pridelenie prístupu.

Dva modely registrácie stojí za to porovnať podľa toho, čo spájajú, nie podľa toho, akým protokolom hovoria.

Žiadosť tvrdí meno, ale nedokazuje ho

Čítajte žiadosť podľa toho, čo skutočne obsahuje: verejný kľúč, žiadateľom zvolený subject a vlastný podpis nad oboma. Nič v tejto štruktúre neodkazuje na váš inventár, adresár účtov ani proces schvaľovania. Subject ako cn=finance-laptop je reťazec, ktorý niekto napísal. Kým proces vydávania neoverí tento reťazec voči záznamu, ktorému dôveruje, je certifikát tvrdenie s priloženým podpisom. Tento rozdiel je celý dôvod existencie procesu registrácie.

Dôsledok je prevádzkovo dôležitý. Certifikačná autorita nikdy nepotrebuje súkromný kľúč klienta na vydanie certifikátu a proces, ktorý ho žiada, si pomýlil podpisovanie s úschovou kľúčov. Generovanie nechajte na koncovom bode a posielajte len verejnú polovicu.

Porovnajte modely podľa toho, čo spájajú

Ručné podpisovanie spája to, čo si operátor pamätá overiť. Automatizovaná služba registrácie spája overenú žiadosť s rozhodnutím, ktoré služba dokáže presadiť, a RFC 7030 opisuje jeden taký návrh, kde sa klient overí pred vrátením certifikátu. Rozdiel, ktorý prežije audit, nie je automatizácia; je to, či kontrola identity prebieha vo vnútri cesty vydávania alebo vedľa nej.

Oba modely musia stále odpovedať na tie isté tri otázky. Kto žiada, na akom zariadení alebo role a na ako dlho. Tiketovací systém, ktorý odpovede zaznamenáva, robí skutočnú prácu; rad, kde sa niekto pozerá na všeobecné meno, nerobí, nech je certifikát neskôr naformátovaný akokoľvek starostlivo.

Model vyberajte podľa počtu registrácií, ktoré očakávate, a podľa obmeny zariadení. Niekoľko serverov ročne zvládne ručnú revíziu s písomným kontrolným zoznamom. Park notebookov nie.

Zaznamenajte životný cyklus od prvého vydania

V momente vydania uložte identifikátor certifikátu, vlastníka, zamýšľané použitie, platnosť a cestu odstránenia, nie pri prvom incidente. Zamýšľané použitie patrí do samotného certifikátu prostredníctvom rozšíreného použitia kľúča a záznam s ním musí súhlasiť. Certifikát vytvorený na autentifikáciu klientov nesmie byť nerozoznateľný od certifikátu pre server.

Naplánujte obnovu a odvolanie strateného zariadenia skôr, než vydáte desiaty profil. Certifikát zdieľaný naprieč oddelením mení cielené odstránenie na výpadok a toto rozhodnutie je oveľa lacnejšie prehodnotiť teraz ako počas piatkového incidentu.

Skontrolujte vydaný certifikát, potom prístup

Po registrácii skontrolujte, čo bolo vydané, a potvrďte, že reťazí k autorite, ktorú očakávate. Dva príkazy pokrývajú bežné chyby: certifikát s nesprávnym použitím a reťaz, ktorý funguje len preto, že klient je nastavený ignorovať validáciu.

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 prístup, nie artefakt. Certifikát ustanovuje identitu a politika stále rozhoduje, ku ktorým službám táto identita môže dosiahnuť. Skontrolujte oboje, pretože správny artefakt s príliš širokou politikou tiež neprejde revíziou. Potvrďte, že klient sa autentifikuje a dostáva len zamýšľané trasy alebo zdroje. Zapíšte, čo ste pozorovali, nie to, čo mal profil robiť.

Profil, ktorý funguje z nesprávneho dôvodu, napríklad zhodné všeobecné meno a žiadna kontrola identity, bude fungovať ďalej aj po odstránení kontroly, o ktorej ste si mysleli, že ju máte.