Conexión rechazada no es un problema de certificado: guía de VPN

El cliente dice que la conexión fue rechazada justo después de regenerar la CRL, así que la CRL parece culpable. No lo es. El rechazo es una respuesta de la capa de transporte, y la validación del certificado ocurre más tarde, dentro del handshake del túnel. El momento es contexto, no prueba.

Dos comprobaciones separan los casos en menos de un minuto, y ninguna de ellas toca los ajustes de confianza.

Lea el error en la capa que lo produjo

Un ECONNREFUSED de connect significa que el intento de transporte fue rechazado: algo respondió con un reset, o la pila informó de un puerto inalcanzable. Un problema de certificado no puede producir ese error, porque el handshake TLS nunca comienza sin una conexión de transporte. Si ve un rechazo, el cliente nunca llegó lo bastante lejos para presentar un certificado. Ese único hecho descarta la revocación como causa.

Lo contrario también se cumple. Un certificado revocado produce una conexión TCP completada y un handshake fallido, registrado en el servidor como error de verificación.

Rechazo de TCP: nadie está escuchando

Para TCP, compruebe si la instancia prevista se está ejecutando y está ligada a la dirección y el puerto del perfil. ss -lntp muestra los oyentes, y su ausencia es la explicación habitual. Un cortafuegos que rechaza en lugar de descartar produce el mismo mensaje en el lado del cliente, por eso comprueba ambos.

Compruebe también la familia de direcciones. Un servicio ligado a 127.0.0.1 o solo a IPv6 rechazará a un cliente que resuelve a la otra.

Después lea el registro del servicio en lugar de adivinar. Un reinicio tras el mantenimiento de la CA puede fallar en un archivo ilegible o ausente y no llegar nunca al estado de escucha, y el registro nombra el archivo. Eso es un fallo de arranque, un error distinto de un certificado rechazado.

UDP no tiene handshake que rechazar

OpenVPN sobre UDP no establece una conexión en el sentido de TCP, así que no hay nada que rechazar en el momento de connect. En Linux, un error que muestra un socket UDP puede venir de un ICMP port-unreachable generado por un datagrama anterior. La página de manual udp(7) describe ese comportamiento asíncrono.

Por eso un cliente UDP puede imprimir un rechazo mientras el proceso del servidor se ejecuta pero no está ligado a la dirección esperada.

Dónde se comprueba realmente una CRL

La CRL se consulta durante el handshake TLS, después de que el par presente su certificado, y solo si la configuración del servidor lo permite. La opción crl-verify de OpenVPN apunta al archivo, y un fallo aparece en el registro del servidor como error de verificación que nombra el certificado.

Un cliente revocado, por tanto, conecta en la capa de transporte y luego falla la autenticación. Mismo servidor, mismo puerto, mensaje completamente distinto.

Compruebe el emisor y las fechas de validez de la CRL cuando llegue a esa etapa. Una CRL firmada por la CA equivocada, o una que caducó antes de que el cliente se conectara, produce errores de verificación que no tienen nada que ver con el certificado del propio cliente.

Una guía breve para la próxima vez

Confirme primero el transporte: oyente presente, familia de direcciones correcta, cortafuegos que no rechaza. Después confirme que el servicio alcanzó su estado de escucha leyendo el registro de arranque. Y solo entonces mire los errores de handshake en busca de mensajes de verificación. Mantenga ese orden fijo, porque cada paso elimina toda una clase de causas.

Anote el transporte, el destino resuelto, el puerto y el texto exacto del error. Reinstalar el cliente destruye esa evidencia y normalmente no cambia nada.