OpenVPN sin CA: cómo peer-fingerprint verifica a los pares

Un despliegue pequeño recurre a las huellas porque una autoridad de certificación parece una infraestructura para la que nadie tiene tiempo. El instinto es razonable, pero el atajo que la gente toma en su lugar—copiar un secreto del canal de datos a ambos extremos—no lo es. Una configuración peer-fingerprint mantiene intacta la estructura TLS: cada lado sigue teniendo su propia clave privada y su certificado, y cada lado sigue verificando al otro. Lo que cambia es dónde se ancla la verificación: de un emisor de confianza a una lista corta de resúmenes fijados. Como un resumen cubre el certificado completo y no un nombre, la renovación se convierte en la operación que realmente consume tiempo.

A qué se compromete en realidad la huella

La huella de un certificado es un resumen del certificado completo codificado en DER, no de su clave pública ni del nombre de su sujeto. Por eso dos certificados con nombres idénticos y la misma clave pero fechas de validez distintas tienen huellas distintas. Eso es lo que hace precisa la fijación, y también lo que hace disruptiva la renovación. Una fijación no puede significar confiar en una clave en general, porque nombra un artefacto en un momento de su vida. Cualquiera puede conocer el resumen, y conocerlo no demuestra nada por sí mismo.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Poseer la clave privada correspondiente es lo que demuestra que el par tiene ese certificado, y el resumen es cómo el otro lado decide si esperaba ese certificado. Esa separación es la razón por la que este diseño no es el antiguo arreglo de secreto compartido: una clave compartida autentica a cualquiera que conozca los mismos bytes, mientras que una fijación autentica un certificado. Un dispositivo distinto obtiene su propia entrada en lugar de una copia del mismo secreto, lo que es una diferencia pequeña en archivos y grande en alcance del daño.

El mapa es recíproco, no simétrico

Cada extremo necesita dos cosas: su propia clave privada con el certificado, y una declaración sobre qué certificados de pares aceptará. En el cliente esa declaración es el resumen del certificado del servidor; en el servidor es la lista de resúmenes de clientes inscritos. Un ejemplo oficial para configuraciones pequeñas de Community 2.6 muestra el arreglo con peer-fingerprint, y vale la pena leerlo antes de elegir este modelo de confianza para un despliegue real. Las dos direcciones no son una lista invertida, y no fallan en el mismo momento.

Añadir un dispositivo edita una lista de permitidos en el servidor, sin copiar el material privado de un cliente existente y sin mover la clave del servidor a ningún sitio. Las dos direcciones también fallan de forma independiente, lo que resulta útil durante el diagnóstico: el lado que cierra el handshake es el lado cuya expectativa no se cumplió. Si el cliente rechaza al servidor, el resumen no coincide con el certificado presentado. Si el servidor rechaza al cliente, falta el resumen de ese cliente en la lista, o el cliente presenta un certificado distinto del que se inscribió.

Inscripción: cómo se une un dispositivo nuevo

Genere la clave y el certificado del dispositivo nuevo donde vivirá la clave privada, y luego mueva solo el artefacto público a la parte que debe fijarlo. Transfiera el resumen esperado por un canal en el que ya confíe, y compare el certificado completo en lugar de un nombre que parezca familiar. Un resumen copiado de la misma descarga no verificada que el certificado solo demuestra que los dos archivos concuerdan entre sí. Es una comprobación de consistencia y no de identidad, y es la forma más silenciosa en que este diseño se debilita.

En el servidor, añadir el resumen es un cambio de configuración que pasa por el gestor habitual y va seguido de una reconexión. Confirme que el dispositivo nuevo se conecta y que un dispositivo cuyo resumen se eliminó ya no lo hace. Una prueba que solo cubre el caso positivo deja la lista de permitidos sin verificar, que es exactamente el estado en el que estará dentro de seis meses.

La renovación es el momento caro

Cada certificado caduca, y un certificado nuevo tiene un resumen nuevo incluso cuando la clave y los nombres siguen igual. Bajo un emisor, la renovación es transparente para los pares que confían en ese emisor; bajo la fijación, es un evento de inscripción para cada par que fija el certificado.

Planifique el orden antes de la fecha de caducidad y no después. Distribuya el resumen nuevo a las partes que lo verifican, aplique el cambio y solo entonces sustituya el certificado en el extremo. Ese orden no deja ninguna ventana en la que los dos lados discrepen sobre qué certificado es el actual. Mantenga también la propia lista en revisión, porque una lista fijada acumula entradas de dispositivos retirados hace meses. Cada entrada obsoleta es una identidad que aún se autentica si su clave sobrevive, así que eliminar una es una acción de seguridad y no una tarea de mantenimiento.

Qué no decide el mapa de confianza

La autenticación es una capa, y el mapa fijado no dice nada sobre el conjunto de direcciones, las rutas empujadas, la MTU de la ruta ni la política del cortafuegos. Siguen siendo configuración separada con modos de fallo separados. Un túnel que se autentica y no pasa tráfico es una investigación distinta de uno que nunca se levanta.

El mapa tampoco escala indefinidamente, y una PKI basada en emisor es donde acaban los despliegues más grandes. Esa preferencia tiene que ver con las operaciones y no con la criptografía, porque añadir y retirar identidades a través de una sola autoridad es más barato que editar una lista en cada par a medida que crece la flota. Donde una implementación de cliente no admite la opción, la respuesta es un modelo de confianza compatible que ese cliente documente, o un reemplazo admitido. Silenciar el aviso de verificación no añade ese soporte, y todo el valor del diseño es que la verificación sigue ocurriendo.