Un CSR por sí solo no es inscripción: qué debe comprobar una CA de VPN

Una solicitud de firma de certificado lleva una clave pública y un sujeto solicitado, firmados con la clave privada correspondiente. Esa firma demuestra que el solicitante posee la clave. No demuestra que tenga derecho al nombre, al dispositivo o al rol de VPN que pide, y tratarla como si lo demostrara es justo cómo un tique de help desk se convierte en una concesión de acceso.

Merece la pena comparar dos modelos de inscripción por lo que vinculan, no por el protocolo que hablan.

Una solicitud afirma un nombre, no lo demuestra

Lea la solicitud por lo que realmente contiene: una clave pública, un sujeto elegido por el solicitante y una autofirma sobre ambos. Nada en esa estructura remite a su inventario, su directorio de cuentas ni su flujo de aprobación. Un sujeto como cn=finance-laptop es una cadena que alguien escribió. Hasta que el proceso de emisión compruebe esa cadena contra un registro en el que confía, el certificado es una afirmación con una firma adjunta. Esa distinción es la razón entera de que exista un proceso de inscripción.

El corolario importa en la operación. Una autoridad de certificación nunca necesita la clave privada del cliente para emitir un certificado, y un flujo que la pide ha confundido la firma con la custodia de claves. Mantenga la generación en el extremo y envíe solo la mitad pública.

Compare los modelos por lo que vinculan

La firma manual vincula lo que el operador recuerda comprobar. Un servicio de inscripción automatizado vincula una solicitud autenticada a una decisión que el servicio puede imponer, y RFC 7030 describe un diseño así en el que el cliente se autentica antes de que se devuelva un certificado. La diferencia que sobrevive a una auditoría no es la automatización; es si la comprobación de identidad ocurre dentro de la ruta de emisión o al lado.

Ambos modelos aún deben responder las mismas tres preguntas. Quién pregunta, en qué dispositivo o rol, y por cuánto tiempo. Un sistema de tiques que registra las respuestas hace trabajo real; una cola donde alguien mira un nombre común no, por mucho cuidado con que se formatee luego el certificado.

Elija el modelo por el número de inscripciones que espera y por la rotación de dispositivos. Unos pocos servidores al año sobreviven a una revisión manual con una lista de comprobación escrita. Una flota de portátiles no.

Registre el ciclo de vida desde la primera emisión

Guarde el identificador del certificado, el propietario, el uso previsto, la caducidad y la ruta de retirada en el momento de la emisión, no en el primer incidente. El uso previsto pertenece al propio certificado mediante un uso de clave extendido, y el registro debe concordar con él. Un certificado creado para autenticación de clientes no debe ser indistinguible de uno para un servidor.

Planifique la renovación y la revocación de un dispositivo perdido antes de emitir el décimo perfil. Un certificado compartido por un departamento convierte una retirada puntual en una interrupción, y revisar esa decisión ahora es mucho más barato que durante un incidente de viernes.

Verifique el certificado emitido y luego el acceso

Tras la inscripción, inspeccione lo emitido y confirme que encadena con la autoridad que espera. Dos comandos cubren los errores habituales: un certificado con el uso equivocado y una cadena que solo funciona porque el cliente está configurado para ignorar la 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

Luego pruebe el acceso en lugar del artefacto. Un certificado establece la identidad, y la política sigue decidiendo a qué servicios puede llegar esa identidad. Compruebe ambas cosas, porque un artefacto correcto con una política demasiado amplia también suspende una revisión. Confirme que el cliente se autentica y recibe solo las rutas o los recursos previstos. Anote lo que observó, no lo que el perfil debía hacer.

Un perfil que funciona por la razón equivocada, como un nombre común coincidente y ninguna comprobación de identidad, seguirá funcionando después de que se retire el control que creía tener.