Como um sistema Enterprise Linux com openssl 1.0.1+ verifica se o CN=hostnamevalor no certificado corresponde ao servidor em que reside? Ele usa uma pesquisa DNS reversa simples e antiga no endereço IP do adaptador que está escutando esse aplicativo da web SSL? Ele usa alguma função de biblioteca gethostname? Ele lerá o arquivo /etc/hosts? O nsswitch.conf desempenha um papel?
Atualizar: Depois de falar com outra pessoa, parece que tudo foi feito no lado do navegador/cliente. Contanto que a parte do host da URL corresponda ao valor CN no certificado instalado para esse aplicativo, o navegador estará satisfeito, certo?
Responder1
Sim, o que você descreveu é tecnicamente correto, mas há um pouco mais acontecendo. O navegador determina que o CN do host está correto com base em alguns indicadores.
A principal indicação é que o host que atende o certificado SSL do tráfego HTTPS está sendo atendido pelo domínio correto e que a cadeia de assinatura do certificado também está correta com base na CA (Autoridade de Certificação) que emitiu e assinou em cadeia o certificado.
Você pode usar openssl's s_clientpara ter uma ideia do desempenho do seu navegador.
Exemplo
$ openssl s_client -connect encrypted.google.com:443 < /dev/null | head -10
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
...
...
DONE
Se você usar este comando você notará o CN que foi usado ao gerar os certificados SSL:
$ openssl s_client -connect encrypted.google.com:443 < /dev/null|& grep "CN.*google"
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Portanto, o navegador confirmará se o nome do host que atende este certificado está dentro da hierarquia CN=...incluída no certificado.
SNI
Antigamente, você precisava ter um endereço IP específico reservado para o nome de host de cada servidor SSL que desejava usar por HTTPS. No entanto, este não é mais o caso graças ao SNI (Server Name Indication).
excerto
Isso funciona muito bem quando um site tem um certificado SSL instalado por endereço IP (isso costumava ser um requisito difícil). Com a Indicação de Nome de Servidor (SNI), um servidor web pode ter vários certificados SSL instalados no mesmo endereço IP. Os navegadores compatíveis com SNI especificarão o nome do host do servidor que estão tentando acessar durante o processo inicial de handshake. Isso permite que o servidor web determine o certificado SSL correto a ser usado para a conexão.
Novamente usando opensslvocê pode simular o que seu navegador estaria fazendo neste cenário:
$ openssl s_client -connect someserver:443 -servername sslsite-example.com
excerto
A negociação SSL deve ocorrer antes do envio da solicitação HTTP ao servidor remoto. Isso significa que o navegador e o servidor precisam fazer a troca de certificados no início do processo e o navegador não terá a oportunidade de especificar qual site está tentando acessar. O SNI corrige isso permitindo um tipo de troca de cabeçalho Host: durante o processo de negociação SSL.