Un CSR da solo non è iscrizione: cosa deve verificare una CA VPN
Una richiesta di firma prova solo il possesso della chiave. Confrontate i modelli di iscrizione per ciò che vincolano prima che la CA conceda l’accesso VPN.
Una richiesta di firma di certificato porta una chiave pubblica e un soggetto richiesto, firmati con la chiave privata corrispondente. Quella firma prova che il richiedente possiede la chiave. Non prova che abbia diritto al nome, al dispositivo o al ruolo VPN richiesti, e trattarla come se lo provasse è esattamente come un ticket di help desk diventa una concessione di accesso.
Vale la pena confrontare due modelli di iscrizione per ciò che vincolano, non per il protocollo che parlano.
Una richiesta afferma un nome, non lo prova
Leggete la richiesta per ciò che contiene davvero: una chiave pubblica, un soggetto scelto dal richiedente e un’autofirma su entrambi. Nulla in quella struttura rimanda al vostro inventario, alla directory degli account o al flusso di approvazione. Un soggetto come cn=finance-laptop è una stringa che qualcuno ha digitato. Finché il processo di emissione non verifica quella stringa contro un record di cui si fida, il certificato è un’affermazione con una firma allegata. Questa distinzione è l’intera ragione per cui esiste un processo di iscrizione.
Il corollario conta sul piano operativo. Un’autorità di certificazione non ha mai bisogno della chiave privata del client per emettere un certificato, e un flusso che la chiede ha confuso la firma con la custodia delle chiavi. Tenete la generazione sull’endpoint e inviate solo la metà pubblica.
Confrontate i modelli per ciò che vincolano
La firma manuale vincola ciò che l’operatore ricorda di verificare. Un servizio di iscrizione automatizzato vincola una richiesta autenticata a una decisione che il servizio può imporre, e RFC 7030 descrive un progetto del genere in cui il client si autentica prima che un certificato venga restituito. La differenza che sopravvive a un audit non è l’automazione; è se il controllo dell’identità avviene dentro il percorso di emissione o accanto.
Entrambi i modelli devono ancora rispondere alle stesse tre domande. Chi chiede, su quale dispositivo o ruolo, e per quanto tempo. Un sistema di ticket che registra le risposte fa un lavoro reale; una coda in cui qualcuno guarda un nome comune no, per quanto accuratamente il certificato venga poi formattato.
Scegliete il modello in base al numero di iscrizioni attese e al ricambio dei dispositivi. Qualche server all’anno sopravvive a una revisione manuale con una lista di controllo scritta. Una flotta di portatili no.
Registrate il ciclo di vita dalla prima emissione
Memorizzate l’identificatore del certificato, il proprietario, l’uso previsto, la scadenza e il percorso di rimozione al momento dell’emissione, non al primo incidente. L’uso previsto appartiene al certificato stesso tramite un uso della chiave esteso, e il record deve concordare con esso. Un certificato creato per l’autenticazione client non deve essere indistinguibile da uno per un server.
Pianificate il rinnovo e la revoca di un dispositivo smarrito prima di emettere il decimo profilo. Un certificato condiviso da un reparto trasforma una rimozione mirata in un’interruzione, e rivedere quella decisione ora costa molto meno che durante un incidente di venerdì.
Verificate il certificato emesso, poi l’accesso
Dopo l’iscrizione, ispezionate ciò che è stato emesso e confermate che si concatena all’autorità attesa. Due comandi coprono gli errori comuni: un certificato con l’uso sbagliato e una catena che funziona solo perché il client è configurato per ignorare la validazione.
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
Poi provate l’accesso invece dell’artefatto. Un certificato stabilisce l’identità, e la policy decide ancora a quali servizi quell’identità può arrivare. Verificate entrambe le cose, perché un artefatto corretto con una policy troppo ampia fallisce comunque una revisione. Confermate che il client si autentica e riceve solo le rotte o le risorse previste. Annotate ciò che avete osservato, non ciò che il profilo avrebbe dovuto fare.
Un profilo che funziona per la ragione sbagliata, come un nome comune corrispondente e nessun controllo dell’identità, continuerà a funzionare dopo che il controllo che credevate di avere sarà rimosso.