Linux openssl CN/Hostname verification against SSL certificate

certificateslinuxopensslssl

How does an Enterprise Linux system with openssl 1.0.1+ verify that the CN=hostname value in the cert matches the server it resides on? Does it use a plain old reverse DNS lookup on the IP address of the adapter that is listening for that SSL web application? Does it use some gethostname Library Function? Will it read the /etc/hosts file? Does nsswitch.conf play a part?

Update:
After speaking with someone else, it appears this is all done on the Browser/client side. As long as the host portion of the URL matches the CN value in the cert which is installed for that application, the browser is happy, is that right?

Best Answer

Yes what you've described is technically correct but there's a little bit more going on. The browser is determining that the host's CN is correct based on a few indicators.

The primary indication is that the host serving the HTTPS traffic's SSL certificate is being served from the correct domain, and that the signing chain of the certificate is also correct based on the CA (Certificate Authority) that issued & chain signed the certificate.

You can use openssl's s_client to get a sense of the back and forth that your browser would also be performing.

Example

$ 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

If you use this command you'll notice the CN that was used when generating the SSL certs:

$ 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

So the browser will confirm that the hostname that's serving this cert falls within the hierarchy of the CN=... that's included in the cert.

SNI

It used to be the case that you had to have a specific IP address set aside for each SSL server's hostname that you wanted to make use of over HTTPS. However this is no longer the case thanks to SNI (Server Name Indication).

excerpt

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.

Again using openssl you can simulate what your browser would be doing in this scenario:

$ openssl s_client -connect someserver:443 -servername sslsite-example.com

excerpt

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.

References

Related Question