Sam CSR še ni registracija: kaj mora preveriti CA VPN

Zahteva za podpis certifikata vsebuje javni ključ in zahtevani subject, podpisana z ustreznim zasebnim ključem. Ta podpis dokazuje, da ima prosilec ključ. Ne dokazuje, da je prosilec upravičen do zahtevanega imena, naprave ali vloge v VPN, in obravnavanje zahteve, kot da to dokazuje, je natanko to, kako vstopnica pri pomoči uporabnikom postane dodelitev dostopa.

Dva modela registracije je vredno primerjati po tem, kaj povežeta, ne po tem, kateri protokol govorita.

Zahteva zatrjuje ime, ne dokazuje ga

Berite zahtevo po tem, kar dejansko vsebuje: javni ključ, subject, ki ga je izbral prosilec, in lastni podpis nad obema. Nič v tej strukturi se ne sklicuje na vaš popis, imenik računov ali postopek odobritve. Subject, kot je cn=finance-laptop, je niz, ki ga je nekdo vtipkal. Dokler postopek izdaje ne preveri tega niza glede na zapis, ki mu zaupa, je certifikat trditev s priloženim podpisom. Ta razlika je ves razlog za obstoj postopka registracije.

Posledica je operativno pomembna. Certifikacijski organ nikoli ne potrebuje zasebnega ključa odjemalca, da bi izdal certifikat, in postopek, ki ga zahteva, je zamenjal podpisovanje s shranjevanjem ključev. Ustvarjanje pustite na končni točki in pošiljajte samo javno polovico.

Primerjajte modela po tem, kaj povežeta

Ročno podpisovanje poveže tisto, česar se operater spomni, da mora preveriti. Avtomatizirana storitev registracije poveže overjeno zahtevo z odločitvijo, ki jo storitev lahko uveljavi, in RFC 7030 opisuje eno takšno zasnovo, kjer se odjemalec overi, preden se certifikat vrne. Razlika, ki preživi revizijo, ni avtomatizacija; je to, ali preverjanje identitete poteka znotraj poti izdaje ali ob njej.

Oba modela morata še vedno odgovoriti na ista tri vprašanja. Kdo sprašuje, na kateri napravi ali vlogi in za kako dolgo. Sistem zahtevkov, ki odgovore zapiše, opravlja resnično delo; vrsta, kjer nekdo strmi v splošno ime, ne, ne glede na to, kako skrbno je certifikat pozneje oblikovan.

Model izberite glede na pričakovano število registracij in menjavo naprav. Nekaj strežnikov na leto vzdrži ročni pregled s pisnim kontrolnim seznamom. Park prenosnikov ne.

Zabeležite življenjski cikel od prve izdaje

V trenutku izdaje shranite identifikator certifikata, lastnika, predvideno uporabo, veljavnost in pot odstranitve, ne ob prvem incidentu. Predvidena uporaba sodi v sam certifikat prek razširjene uporabe ključa in zapis se mora z njo ujemati. Certifikat, izdan za preverjanje odjemalcev, ne sme biti nerazločljiv od tistega za strežnik.

Načrtujte podaljšanje in preklic izgubljene naprave, preden izdate deseti profil. Certifikat, ki si ga deli oddelek, spremeni ciljno odstranitev v prekinitev, in to odločitev je zdaj veliko ceneje pretehtati kot med petkovim incidentom.

Preverite izdani certifikat, nato dostop

Po registraciji preverite, kaj je bilo izdano, in potrdite, da se veriži do organa, ki ga pričakujete. Dva ukaza pokrijeta pogoste napake: certifikat z napačno uporabo in verigo, ki deluje le zato, ker je odjemalec nastavljen tako, da prezre preverjanje veljavnosti.

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

Nato preizkusite dostop, ne artefakta. Certifikat vzpostavi identiteto, politika pa še vedno odloča, katere storitve lahko ta identiteta doseže. Preverite oboje, ker pravilen artefakt s preširoko politiko tudi ne prestane pregleda. Potrdite, da se odjemalec overi in prejme samo predvidene poti ali vire. Zapišite, kar ste opazili, ne tega, kar naj bi profil počel.

Profil, ki deluje iz napačnega razloga, na primer ujemajoče se splošno ime in nobeno preverjanje identitete, bo še naprej deloval, potem ko bo nadzor, za katerega ste mislili, da ga imate, odstranjen.