HTTPS en una IP local: identidad del certificado o nombre de host

Su servicio en https://10.60.0.25 puede tener TLS autenticado incluso sin un nombre DNS. La dirección es la identidad que el cliente debe validar, y el certificado tiene que describirla con exactitud. La decisión es si esa dirección es lo bastante estable para ser una identidad o si un nombre de host sería más fácil de mantener. La VPN responde a la accesibilidad; no responde a esto.

Acierte con la identidad y la confianza, y una URL basada en IP es un diseño legítimo.

Qué valida realmente el cliente

El cliente compara la identidad de referencia de la URL con los nombres alternativos del sujeto del certificado. Para una dirección IP, eso significa una entrada iPAddress igual a la dirección. Un nombre común amigable no es un sustituto.

RFC 9525 separa las identidades de dirección IP de los nombres DNS y define la regla de coincidencia. Poner la dirección solo en la etiqueta del sujeto, o como una entrada de tipo DNS, no produce coincidencia. Por eso el SAN es el campo que hay que inspeccionar cuando aparece una advertencia.

La confianza es una segunda comprobación independiente. Una coincidencia de nombre no arregla una cadena no confiable, un certificado caducado ni un certificado emitido para otro fin.

Decisión uno: si la dirección es lo bastante estable para ser una identidad

Si la dirección es fija durante toda la vida del despliegue, un certificado SAN de IP es simple y honesto. Si el servicio puede moverse, cada movimiento se convierte en un reemplazo de certificado y una actualización coordinada de los clientes.

Un nombre de host estable reduce ese acoplamiento. Los clientes usan el nombre, el DNS aprobado lo asigna a la dirección actual, y un cambio de dirección deja de ser un cambio de identidad. El certificado sigue necesitando renovación, pero la URL no cambia.

Una entrada gestionada en el archivo hosts puede proporcionar la asignación en un entorno pequeño. Añade una responsabilidad de distribución; no sustituye la verificación TLS.

Decisión dos: cómo confiará el cliente en el emisor

Para una CA privada, distribuya el ancla de confianza a los dispositivos previstos mediante un mecanismo aprobado. No enseñe a los usuarios a pasar por alto advertencias ni a instalar un certificado que les entregue una página de inicio de sesión. Si quiere un certificado de confianza pública, revise las reglas actuales del emisor para direcciones privadas antes de planificar en torno a él. La mayoría de los emisores públicos no validarán una IP privada como identidad pública.

Revise el navegador o la aplicación real. Su almacén de confianza y su comportamiento de validación importan más que la documentación general de certificados del sistema operativo. Compruébelo en el dispositivo real, no solo en la consola.

Es posible que la puerta de enlace VPN no sea la máquina que ejecuta la aplicación web, así que no suponga que el certificado del túnel tiene algo que ver con este.

Planifique el cambio de dirección antes de que ocurra

Si 10.60.0.25 pasa a 10.60.0.40, el certificado antiguo ya no describe la URL. Planifique el reemplazo y la actualización del cliente juntos, y nunca desactive la verificación durante el traslado.

Elija la identidad que los usuarios escribirán o que las aplicaciones configurarán, y luego alinee la emisión, la confianza, el despliegue y la renovación en torno a ella. Una página accesible con una advertencia descartada no es el mismo resultado que un servicio cuya identidad verifica el cliente.