HTTPS para um IP privado: identidade do certificado ou nome de host?

O seu serviço em https://10.60.0.25 pode ter TLS autenticado mesmo sem um nome DNS. O endereço é a identidade que o cliente deve validar, e o certificado tem de a descrever com exatidão. A decisão é se esse endereço é estável o suficiente para ser uma identidade, ou se um nome de host seria mais fácil de manter. A VPN responde à acessibilidade; não responde a isto.

Acerte na identidade e na confiança, e um URL baseado em IP é um desenho legítimo.

O que o cliente valida na realidade

O cliente compara a identidade de referência no URL com os nomes alternativos do sujeito do certificado. Para um endereço IP, isso significa uma entrada iPAddress igual ao endereço. Um nome comum amigável não é um substituto.

RFC 9525 separa as identidades de endereço IP dos nomes DNS e define a regra de correspondência. Colocar o endereço apenas no rótulo do sujeito, ou como entrada do tipo DNS, não produz correspondência. Por isso o SAN é o campo a inspecionar quando surge um aviso.

A confiança é uma segunda verificação independente. Uma correspondência de nome não corrige uma cadeia não confiável, um certificado expirado ou um certificado emitido para outro fim.

Decisão um: o endereço é estável o suficiente para ser uma identidade

Se o endereço for fixo durante toda a vida da implantação, um certificado SAN de IP é simples e honesto. Se o serviço se puder deslocar, cada deslocação torna-se numa substituição de certificado e numa atualização coordenada dos clientes.

Um nome de host estável reduz esse acoplamento. Os clientes usam o nome, o DNS aprovado mapeia-o para o endereço atual, e uma mudança de endereço deixa de ser uma mudança de identidade. O certificado continua a precisar de renovação, mas o URL não muda.

Uma entrada gerida no ficheiro hosts pode fornecer o mapeamento num ambiente pequeno. Acrescenta uma responsabilidade de distribuição; não substitui a verificação TLS.

Decisão dois: como o cliente vai confiar no emitente

Para uma CA privada, distribua a âncora de confiança pelos dispositivos previstos através de um mecanismo aprovado. Não ensine os utilizadores a ignorar avisos nem a instalar um certificado entregue por uma página de início de sessão. Se quiser um certificado publicamente fidedigno, verifique as regras atuais do emitente para endereços privados antes de planear com base nelas. A maioria dos emitentes públicos não validará um IP privado como identidade pública.

Reveja o navegador ou a aplicação real. O seu armazenamento de confiança e o seu comportamento de validação importam mais do que a documentação geral de certificados do sistema operativo. Verifique-o no dispositivo real, não apenas na consola.

A gateway VPN pode não ser a máquina que executa a aplicação web, por isso não assuma que o certificado do túnel tenha alguma coisa a ver com este.

Planeie a mudança de endereço antes de acontecer

Se 10.60.0.25 passar a 10.60.0.40, o certificado antigo já não descreve o URL. Planeie a substituição e a atualização do cliente em conjunto, e nunca desative a verificação durante a mudança.

Escolha a identidade que os utilizadores vão escrever ou que as aplicações vão configurar e, depois, alinhe a emissão, a confiança, a implantação e a renovação em torno dela. Uma página acessível com um aviso ignorado não é o mesmo resultado que um serviço cuja identidade o cliente valida.