¿Cómo verifica un sistema Enterprise Linux con openssl 1.0.1+ que el CN=hostnamevalor en el certificado coincida con el servidor en el que reside? ¿Utiliza una antigua búsqueda de DNS inversa en la dirección IP del adaptador que está escuchando esa aplicación web SSL? ¿Utiliza alguna función de biblioteca gethostname? ¿Leerá el archivo /etc/hosts? ¿Nsswitch.conf influye?
Actualizar: Después de hablar con otra persona, parece que todo esto se hace en el lado del navegador/cliente. Siempre que la parte del host de la URL coincida con el valor CN en el certificado instalado para esa aplicación, el navegador estará satisfecho, ¿verdad?
Respuesta1
Sí, lo que has descrito es técnicamente correcto, pero están sucediendo un poco más. El navegador determina que el CN del host es correcto basándose en algunos indicadores.
La indicación principal es que el host que sirve el certificado SSL del tráfico HTTPS está siendo servido desde el dominio correcto y que la cadena de firma del certificado también es correcta según la CA (Autoridad de certificación) que emitió y firmó en cadena el certificado.
Puede utilizar openssl's s_clientpara tener una idea del avance y retroceso que también realizaría su navegador.
Ejemplo
$ 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
Si usa este comando, notará el CN que se usó al generar los 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
Entonces, el navegador confirmará que el nombre de host que proporciona este certificado se encuentra dentro de la jerarquía CN=...incluida en el certificado.
SNI
Solía darse el caso de que tenías que tener una dirección IP específica reservada para el nombre de host de cada servidor SSL que deseabas utilizar a través de HTTPS. Sin embargo, este ya no es el caso gracias a SNI (Indicación de nombre de servidor).
extracto
Esto funciona muy bien cuando un sitio tiene un certificado SSL instalado por dirección IP (esto solía ser un requisito estricto). Con la indicación del nombre del servidor (SNI), un servidor web puede tener varios certificados SSL instalados en la misma dirección IP. Los navegadores compatibles con SNI especificarán el nombre de host del servidor al que intentan acceder durante el proceso de intercambio inicial. Esto permite que el servidor web determine el certificado SSL correcto a utilizar para la conexión.
Nuevamente, opensslpuede simular lo que haría su navegador en este escenario:
$ openssl s_client -connect someserver:443 -servername sslsite-example.com
extracto
La negociación SSL debe realizarse antes de enviar la solicitud HTTP al servidor remoto. Eso significa que el navegador y el servidor tienen que realizar el intercambio de certificados en una etapa más temprana del proceso y el navegador no tendría la oportunidad de especificar a qué sitio está intentando llegar. SNI soluciona este problema permitiendo un tipo de intercambio de encabezado Host: durante el proceso de negociación SSL.