¿Certificado de cliente autofirmado? El servidor VPN sigue rechazándolo

El operador envía una dirección y un nombre de usuario, y el cliente pide un archivo de CA, un certificado y una clave. Generar esos tres localmente parece el siguiente paso obvio. Se produce un certificado en el que solo cree su propia máquina. La confianza del servidor está anclada en una CA que usted no controla, así que el apretón de manos termina antes de empezar.

La confianza vive en el servidor, no en su perfil

La autenticación con certificado es una comparación. El cliente presenta un certificado; la puerta de enlace comprueba si lo firmó una de las CA de su configuración.

Su perfil nombra el archivo de CA que el cliente debe usar para verificar el servidor. No puede nombrar una CA que el servidor deba usar para verificarle a usted. Esa mitad de la configuración no es suya.

Un certificado hecho por usted falla esta comparación incluso cuando es técnicamente perfecto. Tiene una firma válida, un sujeto y fechas, pero el emisor es una CA de la que la puerta de enlace nunca ha oído hablar. El error aparece durante el apretón de manos, después de que el servidor ya haya pedido un certificado. Nada en el perfil del cliente puede cambiar la respuesta.

Por qué un certificado autofirmado no puede sustituirlo

Un certificado autofirmado está firmado con su propia clave. La firma se verifica contra el mismo archivo, lo que lo hace autoconsistente e inútil como credencial para la puerta de enlace de otro.

La puerta de enlace no pregunta si el certificado es coherente internamente. Pregunta si lo firmó un emisor de confianza.

Por eso los mensajes de error confunden. El cliente puede informar de un fallo de verificación que suena a problema del servidor, mientras el servidor registra un emisor desconocido. Ambos describen el mismo desajuste desde extremos opuestos.

La vía de la CSR conserva su clave privada

Todavía puede hacer la mayor parte del trabajo localmente. Genere un par de claves, construya una solicitud de firma de certificado alrededor de la mitad pública y envíe esa solicitud al operador. Solo la solicitud sale de su máquina. La mitad privada se queda donde la generó.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

El operador firma la solicitud con su CA y devuelve un certificado. Su clave privada nunca viajó, y el resultado encadena con el ancla en la que confía la puerta de enlace.

Los servicios gestionados a menudo se saltan la CSR y emiten el paquete completo. Es un intercambio razonable cuando el mismo proveedor ya termina el túnel y tiene la CA. La custodia de la clave no mejora por conservarla, porque el proveedor podría acuñar otra en cualquier momento.

Los paquetes se importan, no se instalan

Los paquetes de proveedores con nombres que suenan a seguridad suelen ser perfiles de OpenVPN. Contienen configuración y a veces certificados, y no instalan nada. Importe el archivo en un cliente que hable el protocolo, y la conexión queda configurada.

La regla de manejo se deduce del contenido. Si el perfil incorpora una clave privada, es una credencial y merece el mismo cuidado que una contraseña: nada de correo, nada de repositorio, nada de carpeta de descargas compartida. Cuando el operador entrega ca.crt, client.crt y client.key por separado, guárdelos juntos con permisos restrictivos y apunte el perfil hacia ellos.

Añada las comprobaciones que el operador pueda haber omitido

Un perfil generado por el router a veces carece de verificación del par. remote-cert-tls server exige que el certificado del par lleve el propósito de autenticación de servidor, de modo que un certificado de cliente no pueda reproducirse como servidor. Esa línea es un cambio pequeño con una justificación clara.

verify-x509-name va más allá cuando el operador puede nombrar el sujeto o el SAN esperados. Ambas son adiciones pequeñas a un perfil, y ambas son defendibles. Inspeccione lo que recibió antes de importarlo.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

La configuración de verificación no es una reparación de una cadena rota. Si el emisor es incorrecto, la respuesta es un certificado de la CA correcta, no un indicador que desactive la comprobación. Desactivar la verificación convierte un fallo de autenticación en uno no detectado.

Pida un solo paquete: el certificado de la autoridad en PEM, un certificado de cliente firmado por esa autoridad, una clave que usted haya generado o que haya llegado por un canal en el que confíe, y el nombre exacto del servidor que el certificado debe presentar. Anote la fecha de caducidad en el mismo mensaje, porque un certificado caducado parece una avería de red meses después.