HTTPS a unha IP privada: identidade do certificado ou nome de host?

O seu servizo en https://10.60.0.25 pode ter TLS autenticado mesmo sen un nome DNS. O enderezo é a identidade que o cliente debe validar, e o certificado ten que describila con exactitude. A decisión é se ese enderezo é o bastante estable para ser unha identidade ou se un nome de host sería máis doado de manter. A VPN responde á accesibilidade; non responde a isto.

Acerta coa identidade e a confianza, e un URL baseado en IP é un deseño lexítimo.

Que valida realmente o cliente

O cliente compara a identidade de referencia do URL cos nomes alternativos do suxeito do certificado. Para un enderezo IP, iso significa unha entrada iPAddress igual ao enderezo. Un nome común amigable non é un substituto.

RFC 9525 separa as identidades de enderezo IP dos nomes DNS e define a regra de coincidencia. Poñer o enderezo só na etiqueta do suxeito, ou como unha entrada de tipo DNS, non produce coincidencia. Por iso o SAN é o campo que hai que inspeccionar cando aparece un aviso.

A confianza é unha segunda comprobación independente. Unha coincidencia de nome non arranxa unha cadea non confiable, un certificado caducado nin un certificado emitido para outro fin.

Decisión un: é o enderezo o bastante estable para ser unha identidade

Se o enderezo é fixo durante toda a vida do despregamento, un certificado SAN de IP é simple e honesto. Se o servizo pode moverse, cada movemento convértese nunha substitución de certificado e nunha actualización coordinada dos clientes.

Un nome de host estable reduce ese acoplamento. Os clientes usan o nome, o DNS aprobado mapéao ao enderezo actual, e un cambio de enderezo deixa de ser un cambio de identidade. O certificado segue necesitando renovación, pero o URL non cambia.

Unha entrada xestionada no ficheiro hosts pode proporcionar a asignación nunha contorna pequena. Engade unha responsabilidade de distribución; non substitúe a verificación TLS.

Decisión dous: como confiará o cliente no emisor

Para unha CA privada, distribúa a áncora de confianza aos dispositivos previstos mediante un mecanismo aprobado. Non ensine aos usuarios a pasar por alto avisos nin a instalar un certificado que lles entregue unha páxina de inicio de sesión. Se quere un certificado de confianza pública, revise as regras actuais do emisor para enderezos privados antes de planificar arredor del. A maioría dos emisores públicos non validarán unha IP privada como identidade pública.

Revise o navegador ou a aplicación real. O seu almacén de confianza e o seu comportamento de validación importan máis que a documentación xeral de certificados do sistema operativo. Compruébeo no dispositivo real, non só na consola.

Pode que a pasarela VPN non sexa a máquina que executa a aplicación web, así que non supoña que o certificado do túnel ten algo que ver con este.

Planifique o cambio de enderezo antes de que ocorra

Se 10.60.0.25 pasa a 10.60.0.40, o certificado antigo xa non describe o URL. Planifique a substitución e a actualización do cliente xuntos, e nunca desactive a verificación durante o traslado.

Escolla a identidade que os usuarios escribirán ou que as aplicacións configurarán, e despois aliñe a emisión, a confianza, o despregamento e a renovación arredor dela. Unha páxina accesible cun aviso descartado non é o mesmo resultado que un servizo cuxa identidade verifica o cliente.