Unha solicitude de sinatura de certificado leva unha chave pública e un suxeito solicitado, asinados coa chave privada correspondente. Esa sinatura proba que o solicitante posúe a chave. Non proba que teña dereito ao nome, ao dispositivo ou ao rol de VPN que pide, e tratala como se o probase é xustamente como un ticket de asistencia se converte nunha concesión de acceso.

Paga a pena comparar dous modelos de rexistro polo que vinculan, non polo protocolo que falan.

Unha solicitude afirma un nome, non o proba

Lea a solicitude polo que realmente contén: unha chave pública, un suxeito escollido polo solicitante e unha autosinatura sobre ambos. Nada nesa estrutura remite ao seu inventario, ao directorio de contas nin ao fluxo de aprobación. Un suxeito como cn=finance-laptop é unha cadea que alguén escribiu. Ata que o proceso de emisión comprobe esa cadea contra un rexistro no que confía, o certificado é unha afirmación cunha sinatura adxunta. Esa distinción é toda a razón pola que existe un proceso de rexistro.

O corolario importa na operación. Unha autoridade de certificación nunca necesita a chave privada do cliente para emitir un certificado, e un fluxo que a pide confundiu a sinatura coa custodia de chaves. Manteña a xeración no extremo e envíe só a metade pública.

Compare os modelos polo que vinculan

A sinatura manual vincula o que o operador lembra comprobar. Un servizo de rexistro automatizado vincula unha solicitude autenticada a unha decisión que o servizo pode impor, e RFC 7030 describe un deseño así no que o cliente se autentica antes de que se devolva un certificado. A diferenza que sobrevive a unha auditoría non é a automatización; é se a comprobación de identidade ocorre dentro da ruta de emisión ou ao lado.

Ambos os modelos aínda deben responder as mesmas tres preguntas. Quen pregunta, en que dispositivo ou rol, e por canto tempo. Un sistema de tickets que rexistra as respostas fai traballo real; unha cola onde alguén mira un nome común non, por moito coidado con que se formatee despois o certificado.

Escolla o modelo polo número de rexistros que espera e pola rotación de dispositivos. Uns poucos servidores ao ano sobreviven a unha revisión manual cunha lista de comprobación escrita. Unha frota de portátiles non.

Rexistre o ciclo de vida desde a primeira emisión

Garde o identificador do certificado, o propietario, o uso previsto, a caducidade e a ruta de retirada no momento da emisión, non no primeiro incidente. O uso previsto pertence ao propio certificado mediante un uso de chave estendido, e o rexistro debe concordar con el. Un certificado creado para autenticación de clientes non debe ser indistinguible dun para un servidor.

Planifique a renovación e a revocación dun dispositivo perdido antes de emitir o décimo perfil. Un certificado compartido por un departamento converte unha retirada puntual nunha interrupción, e revisar esa decisión agora é moito máis barato que durante un incidente de venres.

Verifique o certificado emitido e despois o acceso

Tras o rexistro, inspeccione o emitido e confirme que encadea coa autoridade que espera. Dous comandos cobren os erros habituais: un certificado co uso equivocado e unha cadea que só funciona porque o cliente está configurado para ignorar a validación.

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

Despois probe o acceso en lugar do artefacto. Un certificado establece a identidade, e a política segue decidindo a que servizos pode chegar esa identidade. Comprobe ambas as cousas, porque un artefacto correcto cunha política demasiado ampla tamén suspende unha revisión. Confirme que o cliente se autentica e recibe só as rutas ou os recursos previstos. Anote o que observou, non o que o perfil debía facer.

Un perfil que funciona pola razón equivocada, como un nome común coincidente e ningunha comprobación de identidade, seguirá funcionando despois de que se retire o control que cría ter.

Artigos relacionados