0

I have a webserver, that I run a small side business on (www.trailmyx.com). Recently I began developing some basic SSL socket code (in C++) and I wrote a small test program that connects with OpenSSl and does an http GET. I can use my client successfully against www.google.com on port 443 (or any other site) except my own.

When I attempt to SSL_get_verify_result(ssl) against my own server, I get back: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT.

Now, when I go to my web site in a browser (https://www.trailmyx.com) I can examine the cert and everything looks OK... It doesn't show up as self signed.

Similarly, when I use wget against my server I get the same self signed certificate error.

My gut feeling is that somehow my site is misconfigured, but if so, how can the browsers do it? Is their some other sequence of OpenSSL calls the browsers know to make?

Note: When wget against my server returns, it prints some information from the certificate. None of that information is valid (for example: /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit) I strongly suspect that for some reason, under certain circumstance apache is returning a self signed cert... but why? And how are the browsers doing it? BTW- CURL works just fine.

dicroce
  • 45,396
  • 28
  • 101
  • 140
  • 1
    Maybe your browser's list of trusted CA's is different than the one OpenSSL is using? – Brendan Long Feb 22 '12 at 18:30
  • @BrendanLong - If so, why the SELF_SIGNED_CERT error? Instead of a more generic error that it just failed to authenticate? – dicroce Feb 22 '12 at 18:35
  • Also, wget https://www.godaddy.com (which fails against my server) works against https://www.godaddy.com (who is the CA)... – dicroce Feb 22 '12 at 18:37

2 Answers2

5

I've tried openssl s_client -connect www.trailmyx.com:443 -showcerts and it indeed shows your certificate as self-signed:

Server certificate subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ip-97-74-119-124.ip.secureserver.net/emailAddress=root@ip-97-74-119-124.ip.secureserver.net issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ip-97-74-119-124.ip.secureserver.net/emailAddress=root@ip-97-74-119-124.ip.secureserver.net

Maybe your server is using Server Name Indication (SNI) to allow name-based virtual hosts in combination in SSL?

Update: My hunch was right: you need to use SNI and TLS in order for it to work. This command shows the expected certificate:

openssl s_client -connect www.trailmyx.com:443 -servername www.trailmyx.com -tls1

dr. Sybren
  • 829
  • 5
  • 18
  • Actually, when I use that command even WITHOUT the -tls1, it still is able verify. – dicroce Feb 22 '12 at 21:19
  • @dicroce: that probably depends on your setup like your global OpenSSL configuration. I needed the -tls1 on my Ubuntu server. When I run explicitly with `-no_tls1` I get the wrong certificate, so it's clear that TLS is required. – dr. Sybren Feb 24 '12 at 17:03
0

According to the documentation:

X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: self signed certificate

the passed certificate is self signed and the same certificate cannot be found in the list of trusted certificates.

Which sounds to me like it could mean that it doesn't trust your CA. It's strange though since GoDaddy is old and trusted by just about everyone.

You could try running it against a different list of CA's with the -CAFile option.

EDIT: It's also possible you're missing an intermediate certificate. See this question. Basically if you have:

  • A trusts B
  • B trusts you

And you have A's certificate and your certificate, then you still need B's certificate for verification to work.

Community
  • 1
  • 1
Brendan Long
  • 53,280
  • 21
  • 146
  • 188