Dos certificados OpenVPN, un solo nombre CCD: qué salió mal

Dos certificados de cliente con números de serie distintos, claves distintas e incluso sujetos completos distintos aún pueden resolverse en un solo archivo de política, porque el servidor no mira nada de eso. Lee un nombre del certificado y abre el archivo de configuración de cliente correspondiente. Si ambos certificados llevan el mismo nombre, el segundo hereda la política del primero en el momento en que se conecta.

La colisión se crea en la inscripción y solo se descubre al conectar, normalmente cuando un dispositivo recibe una dirección o un conjunto de rutas que pertenecen a otra máquina. Prevenirlo significa acordar qué campo asigna el servidor y luego reservar ese valor antes de que se firme nada.

Sus herramientas de certificados no le avisarán, porque la unicidad dentro de X.509 y la unicidad de un nombre de política OpenVPN son requisitos distintos que aplican sistemas distintos.

El servidor busca un nombre, no una huella

Con la asignación habitual basada en certificados, el servidor toma el nombre común del certificado presentado y busca un archivo con ese nombre en su directorio de configuración de clientes. Ese archivo puede fijar una dirección estática, enviar rutas o aplicar marcas de cortafuegos por cliente. La búsqueda es una coincidencia de cadena con un nombre de archivo, así que las mayúsculas, los espacios y la puntuación importan.

Algunos despliegues intercambian deliberadamente la asignación para que un nombre de usuario autenticado sustituya al nombre común, y entonces el nombre de usuario es lo que debe ser único. En cualquier caso, el valor que selecciona la política es el valor que usted reserva. Decida cuál es antes de emitir nada; adivinar tras una colisión cuesta más que preguntar.

Donde dos autoridades coinciden en el mismo nombre

Una organización que acepta certificados de más de una autoridad emisora ejecuta dos procesos de inscripción independientes que escriben en un mismo espacio de nombres. Las reglas de unicidad propias de cada autoridad se aplican dentro de ella, de modo que ambas pueden emitir legítimamente para el mismo nombre común sin que ninguna note nada raro.

Los números de serie no ayudan. X.509 exige que un número de serie sea único dentro del ámbito de su emisor, lo cual es una propiedad de la contabilidad de esa autoridad y no una identidad global del dispositivo. La comprobación del sujeto también es una prueba distinta de la del nombre común: dos certificados pueden compartir un CN pero diferir en la unidad organizativa y, por tanto, llevar sujetos distintos. Todas esas propiedades pueden cumplirse mientras el servidor sigue asignando ambos certificados a un solo nombre de archivo.

La documentación de OpenSSL CA cubre el ajuste unique_subject que rige la opinión de su propia base de datos, y el punto de partida honesto es leer su configuración de emisión en lugar de suponer que se aplica algún valor predeterminado concreto de EasyRSA u OpenSSL.

Reserve el nombre efectivo antes de firmar

Mantenga un registro que asigne un dispositivo a su registro aprobado y de ahí a un nombre de archivo de política exacto, de modo que un nombre se asigne una vez y siga asignado. La reserva debe ser atómica, lo que en la práctica significa una restricción de base de datos o un bloqueo en torno al paso de asignar y luego firmar, no una hoja de cálculo que editan dos personas.

Después haga que la comprobación forme parte de la emisión: rechace firmar cuando el nombre solicitado ya exista e incluya en esa comprobación a todas las autoridades en las que confía el servidor, porque un nombre reservado por la otra autoridad está igual de ocupado. Una solicitud rechazada con un motivo claro sale más barata que un tique sobre un dispositivo que no deja de recibir la dirección estática de otro.

La renovación reutiliza un nombre a propósito

Reemitir para un dispositivo existente debería producir un número de serie nuevo bajo el mismo nombre de política, y eso es una reutilización legítima y no una colisión. Lo que hay que decidir de antemano es el solapamiento: si los certificados viejo y nuevo pueden ser válidos a la vez, y cómo se retira la credencial antigua.

No recurra a duplicate-cn para resolver esto. Esa opción del servidor rige las conexiones simultáneas que presentan el mismo nombre; no bloquea la inscripción, y activarla no hace que una dirección estática compartida sea segura para dos máquinas a la vez. La revocación normalmente identifica un certificado por emisor y número de serie, así que retirar la credencial antigua no tiene por qué invalidar su reemplazo siempre que el servidor reciba y aplique los datos de revocación correctos.

Confirme la asignación con las herramientas de la máquina

Antes de entregar a un dispositivo su nueva credencial, lea el nombre del certificado tal como lo hará el servidor y luego compárelo con el archivo de política que espera que se seleccione.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

El primer comando imprime los campos del sujeto por separado, lo que hace visibles de inmediato una unidad organizativa perdida o un espacio duplicado. El segundo confirma que existe un archivo de política exactamente con ese nombre, y el tercero muestra si el servidor está configurado para permitir varias sesiones con un mismo nombre. Ejecute los tres sobre un certificado nuevo antes de que salga del paso de inscripción, mientras un error todavía cuesta una firma en lugar de un incidente. Guarde la salida con el tique para que la siguiente persona vea qué nombre recibió realmente el servidor.

Termine con una conexión real y compare la dirección asignada y las rutas empujadas con el archivo de política, y no con lo que pensaba escribir. Si dos dispositivos informan de la misma dirección estática, el registro tiene una colisión que ninguna inspección de certificados revelará jamás.