Üksi CSR ei ole registreerimine: mida VPN CA peab kontrollima

Sertifikaadi allkirjataotlus sisaldab avalikku võtit ja soovitud subjekti, mis on allkirjastatud vastava privaatvõtmega. See allkiri tõendab, et taotlejal on võti olemas. See ei tõenda, et taotlejal on õigus nimele, seadmele või VPN-i rollile, mida taotletakse, ja taotluse käsitlemine nii, nagu see seda tõendaks, on täpselt see, kuidas abilaua piletist saab juurdepääsu andmine.

Kaht registreerimismudelit tasub võrrelda selle järgi, mida need seovad, mitte selle järgi, millist protokolli need räägivad.

Taotlus väidab nime, see ei tõenda seda

Lugege taotlust selle järgi, mida see tegelikult sisaldab: avalik võti, taotleja valitud subjekt ja allkiri mõlema kohal. Selles struktuuris ei viita miski teie varudele, kontode kataloogile ega kinnitusvoole. Subjekt nagu cn=finance-laptop on tekst, mille keegi sisestas. Kuni väljastamisprotsess ei kontrolli seda teksti andmebaasi vastu, mida ta usaldab, on sertifikaat väide koos lisatud allkirjaga. See erinevus on kogu põhjus, miks registreerimisprotsess üldse olemas on.

Järeldusel on töine tähtsus. Sertifitseerimisasutus ei vaja sertifikaadi väljastamiseks kunagi kliendi privaatvõtit, ja voog, mis seda küsib, on ajanud segi allkirjastamise võtmete hoiustamisega. Jätke genereerimine lõpp-punkti ja saatke ainult avalik pool.

Võrrelge mudeleid selle järgi, mida need seovad

Käsitsi allkirjastamine seob selle, mida operaator kontrollida mäletab. Automatiseeritud registreerimisteenus seob autenditud taotluse otsusega, mida teenus suudab jõustada, ja RFC 7030 kirjeldab ühte sellist lahendust, kus klient autenditakse enne sertifikaadi tagastamist. Auditi üle elav erinevus ei ole automatiseerimine; see on, kas identiteedikontroll toimub väljastamistee sees või selle kõrval.

Mõlemad mudelid peavad ikkagi vastama samale kolmele küsimusele. Kes küsib, millisel seadmel või rollis ja kui kauaks. Piletisüsteem, mis vastused kirja paneb, teeb päris tööd; järjekord, kus keegi jõllitab üldnime, ei tee, ükskõik kui hoolikalt sertifikaat hiljem vormindatakse.

Valige mudel oodatud registreerimiste arvu ja seadmete käibe järgi. Paar serverit aastas peavad vastu käsitsi ülevaatusele kirjaliku kontrollnimekirjaga. Sülearvutite park ei pea.

Kirjendage elutsükkel alates esimesest väljastamisest

Salvestage sertifikaadi identifikaator, omanik, kavandatud kasutus, aegumine ja eemaldamise tee väljastamise hetkel, mitte esimese juhtumi ajal. Kavandatud kasutus kuulub sertifikaadi enda sisse laiendatud võtmekasutuse kaudu ja kirje peab sellega kooskõlas olema. Kliendi autentimiseks loodud sertifikaat ei tohi olla serveri omast eristamatu.

Planeerige uuendamine ja kadunud seadme tühistamine enne kümnenda profiili väljastamist. Osakonna peale jagatud sertifikaat muudab sihitud eemaldamise katkestuseks ja seda otsust on palju odavam nüüd üle vaadata kui reedese juhtumi ajal.

Kontrollige väljastatud sertifikaati, seejärel juurdepääsu

Pärast registreerimist vaadake, mis väljastati, ja kinnitage, et see ahelub oodatud asutuseni. Kaks käsku katavad tavalised vead: vale kasutusega sertifikaat ja ahel, mis töötab ainult sellepärast, et klient on seadistatud valideerimist eirama.

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

Seejärel testige juurdepääsu, mitte artefakti. Sertifikaat loob identiteedi ja poliitika otsustab endiselt, millistele teenustele see identiteet pääseb. Kontrollige mõlemat, sest korrektne artefakt liiga laia poliitikaga ei läbi ikkagi ülevaatust. Kinnitage, et klient autendib end ja saab ainult kavandatud marsruudid või ressursid. Kirjutage üles, mida te täheldasite, mitte mida profiil oleks pidanud tegema.

Profiil, mis töötab vale põhjuse tõttu, näiteks sobiv üldnimi ja identiteedikontrolli puudumine, jätkab töötamist ka pärast seda, kui kontroll, mis te arvasite olevat, on eemaldatud.