Sam CSR nije upis: šta VPN CA mora provjeriti

Zahtjev za potpis certifikata nosi javni ključ i traženi subjekt, potpisan odgovarajućim privatnim ključem. Taj potpis dokazuje da podnosilac posjeduje ključ. Ne dokazuje da podnosilac ima pravo na ime, uređaj ili VPN ulogu koja se traži, a tretiranje zahtjeva kao da to dokazuje jeste način na koji tiket help deska postaje odobrenje pristupa.

Dva modela upisa vrijedi uporediti po tome šta vezuju, a ne po tome kojim protokolom govore.

Zahtjev tvrdi ime, ali ga ne dokazuje

Pročitajte zahtjev po onome što stvarno sadrži: javni ključ, subjekt koji je podnosilac izabrao i vlastiti potpis preko oba. Ništa u toj strukturi ne upućuje na vaš inventar, imenik računa ili tok odobravanja. Subjekt cn=finance-laptop je niz koji je neko otkucao. Dok proces izdavanja ne provjeri taj niz prema zapisu kojem vjeruje, certifikat je tvrdnja s priloženim potpisom. Ta razlika je cijeli razlog postojanja procesa upisa.

Posljedica je operativno važna. Certifikacijsko tijelo nikada ne treba privatni ključ klijenta da bi izdalo certifikat, a tok koji ga traži pobrkao je potpisivanje s čuvanjem ključeva. Držite generisanje na krajnjoj tački i šaljite samo javnu polovinu.

Uporedite modele po tome šta vezuju

Ručno potpisivanje vezuje ono čega se operator sjeti da provjeri. Automatizovana usluga upisa vezuje autentifikovani zahtjev za odluku koju usluga može provesti, a RFC 7030 opisuje jedan takav dizajn gdje se klijent autentifikuje prije nego što se certifikat vrati. Razlika koja preživi reviziju nije automatizacija; nego to da li se provjera identiteta odvija unutar putanje izdavanja ili pored nje.

Oba modela još moraju odgovoriti na ista tri pitanja. Ko pita, na kojem uređaju ili ulozi i na koliko dugo. Sistem tiketa koji bilježi odgovore radi stvarni posao; red u kojem neko gleda u uobičajeno ime ne radi, koliko god certifikat poslije bio pažljivo formatiran.

Odaberite model prema broju upisa koje očekujete i prema prometu uređaja. Nekoliko servera godišnje može proći ručnu reviziju s pisanom kontrolnom listom. Park laptopa ne može.

Zabilježite životni ciklus od prvog izdavanja

Sačuvajte identifikator certifikata, vlasnika, namjeravanu upotrebu, istek i putanju uklanjanja u trenutku izdavanja, a ne kod prvog incidenta. Namjeravana upotreba pripada samom certifikatu kroz prošireno korištenje ključa, a zapis se mora s tim slagati. Certifikat napravljen za autentifikaciju klijenta ne smije biti nerazlučiv od onog za server.

Planirajte obnovu i opoziv izgubljenog uređaja prije nego izdate deseti profil. Certifikat dijeljen kroz odjel pretvara ciljano uklanjanje u prekid rada, a tu odluku je mnogo jeftinije preispitati sada nego tokom petka.

Provjerite izdati certifikat, pa pristup

Nakon upisa pregledajte šta je izdato i potvrdite da se lanča do tijela koje očekujete. Dvije komande pokrivaju uobičajene greške: certifikat s pogrešnom upotrebom i lanac koji radi samo zato što je klijent konfigurisan da zanemari validaciju.

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

Zatim testirajte pristup, a ne artefakt. Certifikat uspostavlja identitet, a politika i dalje odlučuje kojim servisima taj identitet smije pristupiti. Provjerite oboje, jer ispravan artefakt uz preširoku politiku i dalje pada na reviziji. Potvrdite da se klijent autentifikuje i prima samo namjeravane rute ili resurse. Zapišite šta ste primijetili, a ne šta je profil trebao raditi.

Profil koji radi iz pogrešnog razloga, poput podudarnog uobičajenog imena i bez provjere identiteta, nastavit će raditi nakon što kontrola za koju ste mislili da je imate bude uklonjena.