Browser rejects certificate, but openssl s_client works

Question

I'm migrating a secure website. I've installed the same certificate on the new host and pointed the domain name to the new IP address (via my hosts file). However, when I try to hit that server with a web browser, I get certificate verification error.

To complicate matters, the new host is a service that uses SNI. Therefore, the error message I'm shown, that the domain name does not match the cert, is referring to the cert before SNI. I'm doubtful SNI is set up incorrectly since every other connection works.

To try to diagnose the problem, I used openssl s_client. To my dismay, openssl does not have problems connecting, and I see no errors when issuing an HTTP request:

openssl s_client -connect <ipaddress>:443 -servername <domainname> -showcerts -debug

Are there any other tools out there to diagnose why web browsers (I've tested with Chrome, Firefox, and IE) are rejecting a certificate despite the fact that openssl s_client does not?

Here's the abbreviated output from openssl in case you can spot the issue:

CONNECTED(00000003)
Certificate chain
 0 s:<subject details>
   i:<issuer details>
 <certificate>
 1 s:<subject details>
   i:<issuer details>
 <certificate>
 2 s:<subject>
   i:<issuer, same as subject>
 <certificate>
---
Server certificate
[certificate information]
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4392 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: <session id>
    Session-ID-ctx:
    Master-Key: <master key>
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    <hex output>
    Start Time: 1434382473
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

Update:

Chrome reports "Server's certificate does not match the URL," but as I said, this is because of using SNI; it is complaining that the certificate used to initially connect doesn't match the URL. openssl does the SNI thing just fine, so I'm thinking the browser is rejecting the certificate that openssl accepts.

Firefox error:

uses an invalid security certificate. The certificate is only valid for the following names: (Error code: ssl_error_bad_cert_domain)

IE error:

The security certificate presented by this website was issued for a different website's address.

RESOLUTION:

Thanks everyone for your help. Details are hard to provide in my case for a variety of issues. I found the issue though. The certificate was properly installed and accepted. What I did not notice is that the site performed a redirect to a domain for which the cert was not installed properly (www.thedomainname.com). I wish I had noticed earlier.

Answer 1

...despite the fact that openssl s_client does not?

OpenSSL never checks the hostname against the certificate, but browsers do.

...openssl s_client -connect :443 ...

I see that you are using s_client with the IP address and not the hostname. Since you claim to have the proper mapping between name an IP address in your hosts file using the hostname should work too. If it does not, then you might have found the cause of the problem already, i.e. the wrong mapping. Of course you must also use the hostname inside the browser, because (I assume that) the certificate is for the hostname and not the IP address.

Please make also sure that you don't have configured a proxy with the browsers because then the hostname is resolved by the proxy, i.e. not using the hosts file on your local machine.

If it works with s_client and the hostname but not with the browser and the hostname please check exactly the common name and subject alternative names section of the certificate. It must match the hostname given in the URL either exactly or based on the rules for wildcard matching if you have a wildcard certificate. A wildcard matches only a single label, i.e. *.example.com does not match foo.bar.example.com. And example.com is different from www.example.com. Note also that if you have subject alternative names the common name might be ignored (depending on the browser).

If you still have problems then add more details, especially - The exact URL you use. Note that there is a difference if you use www.example.com vs. example.com. - The certificate you see in the browser, especially the common name and the subject alternative name part. And compare this with the certificate you get from s_client and which you consider as correct.

Answer 2

You have provided insufficient details for us to answer the question.

• Exact browser error text might help indicate what the browser actually thinks is the problem
• Certificate details that are currently redacted might shed light
• The redacted s_client output tells us nothing except that TLS got negotiated, which we knew from the fact your browser gave you a certificate verification error

You believe that SNI is the problem. Your next step should be to perform packet captures of the connection via both openssl and a browser, and then compare them. You'll want to pay careful attention to the value of the server_name extension to the client_hello, and the certificate that the server returns. Those are the two particulars that will tell you how SNI is working in both cases. If server_name and server certificate are the same for both clients, then ignore how happy openssl seems and figure out why your browser is unhappy. If they differ, figure out why.

(Note, you don't need to decrypt the packet capture, the details you care about are unencrypted and visible during the negotiation. Wireshark makes it very easy to navigate the structure of handshake packets and see what's there.)

I sympathize that you don't want to drag your domains out here, but it limits how much help you can get.