0

I have a website that has a valid wildcard certificate from Godaddy. When I view it in my browser I get a valid secure certificate (green padlock) and when I examine the certificate within the browser it says secure and signed by godaddy and everything appears normal.

However, if I use openssl s_client -connect my.site.com:443

I get a self signed certificate:

issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd

I don't understand why this is. There seems to be an issue with some of my users that have ssl self-signed errors within their browsers and I think this has something to do with it.

I'm using Ubuntu 11.04 with apache2. Any ideas why this is the case, or how I could further examine the issue?

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
bmilesp
  • 2,559
  • 3
  • 16
  • 14
  • Are you running both clients from the local host or from another computer? – Joachim Isaksson Feb 07 '12 at 15:59
  • Is `my.site.com` resolving to `127.0.0.1` on the server and thus getting a different HTTPS host? – ceejayoz Feb 07 '12 at 16:02
  • possible duplicate of [SSL handshake fails with - a verisign chain certificate - that contains two CA signed certificates and one self-signed certificate](http://stackoverflow.com/questions/4103472/ssl-handshake-fails-with-a-verisign-chain-certificate-that-contains-two-ca-s) – Bruno Feb 07 '12 at 16:06
  • @Joachim - the openssl and my browser tests are on the same cpu, but the user browser tests that have issues are on a separate computer. I cannot replicate the error in a browser on my computer, only for the openssl command do i get see any difference in the ssl examination results. – bmilesp Feb 07 '12 at 16:24
  • @ceejayoz i'm not sure i understand the question. i have in my hosts file: 127.0.0.1 site.com. i'm not sure if the https is also resolving to 127.0.0.1. is there a way to verifiy this? – bmilesp Feb 07 '12 at 16:28
  • @Bruno i've read the link you've sent and used this command: openssl s_client -connect myweb.com:443 -showcerts -CApath /path/to/certs and i was able to see the correct keychain this time! the original openssh command does not fail though so it's not a duplicate issue. – bmilesp Feb 07 '12 at 16:32
  • @bmilesp Do `ping my.site.com` and see what IP it's using. – ceejayoz Feb 07 '12 at 16:34
  • @ceejayoz i get the correct ip of the server (not 127.0.0.1). – bmilesp Feb 07 '12 at 16:35

1 Answers1

0

The general issue with OpenSSL is that it's not pre-configured with a set of trusted CA certificates (unlike your browser). You need to specify it with -CApath or -CAfile.

Another common problem that your users may be facing is that you may be missing intermediate CA certificates. The certificate chain presented by your server (which you can indeed check using openssl s_client, possibly with -showcerts if you want the full details) needs to be presented in the right order, from host certificate to root CA (excluding the root CA, although I've noticed in practice it doesn't hurt to have it), so the one certificate's issuer DN is the next certificate's subject DN (until the issuer DN is the subject DN of one of your trusted CAs).

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • Ok, i can see the certificate chain when i use -CAPATH option. and -showcerts. So you're suggesting, if the certificate chain is 'out of order' or if chain parts are missing it could throw ssl errors to users? – bmilesp Feb 07 '12 at 16:38
  • I'm not sure if the intermediate certificates are in correct order. I know the certificate bundle file was downloaded from godaddy and i would assume they have the correct order. Is there a way to check if the order is correct? – bmilesp Feb 07 '12 at 16:44
  • It could be a problem, yes. To check look at the Certificate Chain (using `openssl_sclient`). Certificate 0 should be your servers, then the `i:` line should be followed by the same `s:` line in the following certificate. (The other common cause of problems is that the host name in your certificate must match that requested by the users in the URL they're using.) – Bruno Feb 07 '12 at 18:05