En CSR alene er ikke registrering: hva en VPN-CA må kontrollere

En forespørsel om sertifikatsignering inneholder en offentlig nøkkel og et ønsket subject, signert med den tilhørende private nøkkelen. Den signaturen beviser at forespørreren har nøkkelen. Den beviser ikke at forespørreren har rett til navnet, enheten eller VPN-rollen som det spørres om, og å behandle forespørselen som om den gjorde det, er nettopp hvordan en helpdesk-billett blir en tilgangstildeling.

To registreringsmodeller er verdt å sammenligne etter hva de binder, ikke etter hvilken protokoll de snakker.

En forespørsel hevder et navn, den beviser det ikke

Les forespørselen for det den faktisk inneholder: en offentlig nøkkel, et subject forespørreren har valgt, og en selvsignatur over begge. Ingenting i den strukturen viser til inventaret ditt, kontokatalogen eller godkjenningsflyten. Et subject som cn=finance-laptop er en streng noen har skrevet inn. Inntil utstedelsesprosessen kontrollerer den strengen mot en post den stoler på, er sertifikatet en påstand med en signatur vedlagt. Den forskjellen er hele grunnen til at en registreringsprosess finnes.

Konsekvensen er operativt viktig. En sertifiseringsmyndighet trenger aldri klientens private nøkkel for å utstede et sertifikat, og en flyt som ber om én, har forvekslet signering med nøkkeloppbevaring. Hold genereringen på endepunktet og send bare den offentlige halvdelen.

Sammenlign modellene etter hva de binder

Manuell signering binder det operatøren husker å kontrollere. En automatisert registreringstjeneste binder en autentisert forespørsel til en beslutning tjenesten kan håndheve, og RFC 7030 beskriver en slik design der klienten autentiserer før et sertifikat returneres. Forskjellen som overlever en revisjon, er ikke automatisering; det er om identitetskontrollen skjer inne i utstedelsesløypa eller ved siden av.

Begge modellene må fortsatt svare på de samme tre spørsmålene. Hvem spør, på hvilken enhet eller rolle, og hvor lenge. Et saksystem som registrerer svarene, gjør ekte arbeid; en kø der noen stirrer på et vanlig navn, gjør det ikke, uansett hvor nøye sertifikatet formateres senere.

Velg modellen etter antallet registreringer du forventer og etter utskiftingen av enheter. Noen få servere i året tåler manuell gjennomgang med en skriftlig sjekkliste. En flåte med bærbare gjør det ikke.

Registrer livssyklusen fra første utstedelse

Lagre sertifikatets identifikator, eieren, tiltenkt bruk, utløp og fjerningsvei i det øyeblikket det utstedes, ikke ved den første hendelsen. Tiltenkt bruk hører hjemme i sertifikatet selv gjennom utvidet nøkkelbruk, og posten skal stemme med det. Et sertifikat laget for klientautentisering bør ikke være umulig å skille fra et for en server.

Planlegg fornyelse og tilbakekalling av tapt enhet før dere utsteder den tiende profilen. Et sertifikat som deles på tvers av en avdeling, gjør en målrettet fjerning til et avbrudd, og den beslutningen er mye billigere å ta opp nå enn under en fredagshendelse.

Kontroller det utstedte sertifikatet, deretter tilgangen

Etter registreringen, undersøk hva som ble utstedt, og bekreft at det kjeder til myndigheten dere forventer. To kommandoer dekker de vanlige feilene: et sertifikat med feil bruk, og en kjede som bare virker fordi klienten er konfigurert til å ignorere validering.

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

Test deretter tilgangen i stedet for artefakten. Et sertifikat fastslår identitet, og policyen avgjør fortsatt hvilke tjenester den identiteten kan nå. Kontroller begge, fordi en korrekt artefakt med en altfor bred policy fortsatt ikke består en revisjon. Bekreft at klienten autentiserer og bare mottar de tiltenkte rutene eller ressursene. Noter det dere observerte, ikke det profilen skulle gjøre.

En profil som virker av feil grunn, for eksempel et samsvarende vanlig navn og ingen identitetskontroll, vil fortsette å virke etter at kontrollen dere trodde dere hadde, er fjernet.