Por qué dos certificados OpenVPN pueden compartir una política CCD

Una CA puede firmar dos certificados que reciben la misma OpenVPN configuración específica de cliente, y nada en ninguno de los dos certificados advierte a nadie. Los números de serie difieren, las claves difieren y los sujetos completos también difieren en cuanto cambia una unidad organizativa. El servidor resuelve la política por cliente mediante un solo nombre, y ese nombre es lo único que debe ser único.

El servidor resuelve un nombre, no un número de serie

Con la búsqueda simple de certificados, el servidor toma el nombre común del certificado presentado y busca una entrada de client-config-dir con ese nombre. El número de serie nunca entra en la búsqueda. Dos certificados que difieren en todos los campos excepto el nombre común acaban en el mismo archivo, así que la segunda conexión hereda la dirección fija y las rutas enviadas del primer dispositivo.

Así es como una comprobación de unicidad del lado de la CA pasa mientras la VPN sigue colisionando. Las dos comprobaciones responden a preguntas distintas.

Decida cuál debe ser el nombre efectivo antes de firmar nada y anótelo junto al dispositivo o la cuenta al que pertenece. Un registro de nombre, propietario, propósito y huella del certificado cubre la mayoría de los despliegues. Sin uno, el archivo de certificados es el único registro de qué nombre pertenece a qué dispositivo, y ese archivo no puede distinguir un reemplazo autorizado de un segundo dispositivo que reclama un nombre existente. Reserve el nombre en la inscripción, bajo un bloqueo si dos operadores pueden emitir al mismo tiempo.

Qué nombre usa realmente la asignación

La búsqueda simple de certificados usa el nombre común. Un servidor configurado para asignar un nombre de usuario autenticado usa ese valor en su lugar, lo que hace que el nombre común del certificado sea irrelevante para la selección de política. Lea la configuración en ejecución para ver qué asignación está vigente.

Ambas asignaciones pueden estar presentes a la vez, y entonces el resultado depende del orden en que el servidor las resuelve. Una asignación de nombre de usuario que recurre al nombre común aceptará en silencio un certificado que el registro nunca aprobó. Escriba el nombre efectivo junto al comando que lo produjo para que el siguiente operador no tenga que redescubrir el orden. Probar una conexión por asignación es barato y zanja la cuestión.

Sea lo que sea lo que produzca la asignación, ese es el valor que hay que reservar. Reservar nombres comunes en la CA mientras el servidor se basa en nombres de usuario reserva lo equivocado.

Dos CA pueden aprobar el mismo nombre

Un servicio de VPN puede confiar en más de una autoridad emisora, y cada autoridad tiene su propia idea de qué nombres están ocupados. Dos CA independientes pueden aprobar el mismo nombre común para dispositivos distintos, y el servidor acepta ambos certificados sin queja. Inventaríe cada autoridad del paquete de confianza, no solo la que normalmente usa para emitir. El fallo aparece la primera vez que se usa un certificado de la segunda autoridad.

El mismo razonamiento se aplica a una CA que impone la unicidad del sujeto completo en lugar de la unicidad del nombre común.

Dos certificados que comparten un nombre común pero difieren en unidad organizativa tienen sujetos distintos, así que la CA no informa de ningún conflicto mientras el servidor ve un solo nombre. Compruebe la configuración que su herramienta emisora usa realmente en lugar de suponer un valor predeterminado. La gestión de unique_subject en la documentación de openssl ca es la palanca relevante allí, y los envoltorios alrededor de esa herramienta suelen exponerla en lugar de sustituirla.

La renovación es una reutilización reservada, no una colisión

Una renovación que conserva el nombre es una reutilización deliberada, y el registro debería decirlo con palabras llanas. Anote la huella antigua y la nueva bajo un solo nombre para que un revisor pueda distinguir un reemplazo de una toma de control. La opción duplicate-cn del servidor no tiene relación: gobierna las sesiones simultáneas, no la inscripción ni las reservas de nombres. Decida cuánto tiempo pueden existir ambas credenciales y cuándo la antigua deja de aceptarse.

Antes de entregar el reemplazo, relea qué contiene realmente el certificado. La línea de sujeto es el campo que el servidor asignará, diga lo que diga el nombre del archivo.

openssl x509 -in device42.crt -noout -subject -serial -issuer

La revocación normalmente identifica un certificado bajo su emisor, así que retirar un número de serie no afecta a un reemplazo emitido correctamente por la misma autoridad. Ese comportamiento es exactamente lo que necesita una renovación limpia, y también es por lo que la revocación no puede limpiar un nombre compartido por dos dispositivos. Valide el nombre efectivo de la política y la dirección asignada en una conexión de prueba antes de que el usuario vea el dispositivo. Después retire la credencial antigua a propósito y anote que lo hizo.