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?
Linux openssl CN/Hostname verification against SSL certificate
linux;openssl;ssl;certificates
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 -10depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authorityverify return:1depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CAverify return:1depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2verify return:1depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.comverify return:1CONNECTED(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---......DONEIf 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.*googledepth=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.comsubject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.comSo 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.SNIIt 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).excerptThis 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 theyre 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.comexcerptSSL 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 wouldnt get the opportunity to specify which site its trying to reach. SNI fixes that by allowing a Host: header type of exchange during the SSL negotiation process.ReferencesUsing OpenSSLs s_client command with web servers using Server Name Indication (SNI)Transport Layer Security - Wikipedia