Sim, o que você descreveu está tecnicamente correto, mas há um pouco mais acontecendo. O navegador está determinando que o CN do host está correto com base em alguns indicadores.
A indicação principal é que o host que atende ao 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 & cadeia assinou o certificado.
Você pode usar openssl do s_client para ter uma idéia do andamento e do andamento 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
Assim, o navegador confirmará que o nome do host que está servindo esse certificado está na hierarquia do CN=... incluído no certificado.
SNI
Costumava acontecer que você tivesse que ter um endereço IP específico reservado para cada nome de host do servidor SSL que você queria usar via HTTPS. No entanto, este não é mais o caso graças ao SNI (Server Name Indication).
trecho
This works really well when a site has one SSL certificate installed per IP address (this used to be a hard requirement). With Server Name Indication (SNI), a web server can have multiple SSL certificates installed on the same IP address. SNI-capable browsers will specify the hostname of the server they’re trying to reach during the initial handshake process. This allows the web server to determine the correct SSL certificate to use for the connection.
Novamente, usando openssl , você pode simular o que seu navegador estaria fazendo nesse cenário:
$ openssl s_client -connect someserver:443 -servername sslsite-example.com
trecho
SSL negotiation must occur prior to sending the HTTP request through to the remote server. That means that the browser and the server have to do the certificate exchange earlier in the process and the browser wouldn’t get the opportunity to specify which site it’s trying to reach. SNI fixes that by allowing a Host: header type of exchange during the SSL negotiation process.