13

A few computers, but not most, are rejecting the SSL certificate from my webserver. The problem seems to be that some computers are rejecting the CA certs. The problem seems to be manifesting on Mac OS X 10.6 when it is not fully updated.

According to http://www.sslshopper.com/index.php?q=ssl-checker.html#hostname=beta.asana.com -- there's no problem.

According to http://certlogik.com/sslchecker/, there's no intermediate certs being sent down.

My cert is from Starfield Technologies, and I'm using sf_bundle.crt from here: certs.godaddy.com/anonymous/repository.seam

I'm handling SSL on my server via stunnel with the following stunnel.conf:

cert = $CODEZ/admin/production/proxy/asana.pem
CAfile = $CODEZ/admin/production/proxy/sf_bundle.crt
pid =
client = no

[<forwarded port>]
accept = 443
connect = 8443

Any ideas what I could be doing wrong?

Jack Stahl
  • 133
  • 1
  • 1
  • 5

3 Answers3

17

The CAFile option configures a CA to use for client authentication certificates; this isn't what you want.

Instead, you want to craft the file in the cert option to contain the entire applicable certificate chain. You'll want to save a backup copy of that file, then make a new one; basically combining the two files, formatted like this:

-----BEGIN CERTIFICATE-----
(certificate from asana.pem file pasted here)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(intermediate certificate here; copy-paste the top chunk from the bundle)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(root certificate here; copy-paste the bottom chunk from the bundle)
-----END CERTIFICATE-----

This will force stunnel to present the full certificate chain to clients.

One further tidbit; the openssl s_client command is very useful for testing certificate chain issues and checking how your service is presenting its certificates.

Edit: Ok.. that certificate bundle's chain is three-deep, but the trust chain looks two-deep. Something's not right.

The top certificate ("Starfield Secure Certification Authority") is signed by an issuer named "Starfield Class 2 Certification Authority" with a thumbprint starting with ad7e1c28.. but the second cert in the bundle, named exactly the same as the first cert's signer, which should be the exact same certificate, has a thumbprint starting with 363e4734, and an expiration date 10 years earlier. Then the third (root) cert is the signer of the included intermediate cert.. but neither of those two has any relation to the first one!

If that didn't make sense, don't worry. Summary: sloppy work, someone seriously dropped the ball building this cert bundle. Your best bet, then, is to export the files in base-64 format from a browser that's successfully validating the chain, pasting them into the format that I listed from there.

Since that's a confusing mess through no fault of your own, I took a guess at your DNS name and grabbed the cert, and I think this should be the full chain you need: http://pastebin.com/Lnr3WHc8

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Thanks this was super useful! I can't upvote because I don't have the rep points, but I would :-) – Jack Stahl Apr 01 '11 at 22:33
  • @Jack If your problem is resolved, you're able to accept the answer even with low rep. I've edited the post to clarify that the cert bundle they've provided is screwed up.. and since it's such a mess, I went ahead and threw together the full chain for you. – Shane Madden Apr 01 '11 at 22:41
1

Qualys SSLLabs is really handy for checking your configuration after changes.

https://www.ssllabs.com/ssldb/analyze.html

Checks that you've got

  • strong ciphers enabled
  • weak ciphers disabled
  • the certificate chain complete and in the correct order
Ben Walding
  • 201
  • 3
  • 9
1

For anyone else facing this problem, Shane's post did the trick, although I also had to include the CAFile. Also when creating the chain, make sure you follow the file naming instructions as per this article

To determine the filename you should use, you can use the c_hash program that comes with OpenSSL (in the /usr/local/ssl/misc directory):

c_hash some_certificate.pem
a4644b49.0 => some_certificate.pem

So, in the above case you'd rename the file to a4644b49.0.
(Note that is a zero, not the letter 'O', after the dot in the filename.)

If you do not have the c_hash program you can run the appropriate OpenSSL command to determine the hash value:

openssl x509 -hash -noout -in some_certificate.pem
a4644b49

And if you're facing this problem bc you're trying to use websockets with android cordova, be sure to manually add wss to your cordova-whitelist stuff, as the * only includes http and https.

Community
  • 1
BrightEyed
  • 111
  • 1
  • The article you link to has a big red banner at the top of it that reads **This page depreciated**, are you sure that this information is correct, as in supported—or as-things-should-be-done, at the time of this writing? – austinian Aug 27 '15 at 13:11
  • 2
    Positive, at least just for the part quoted. stunnel will chuck a wobbly unless you name the certificate chain as the hash of the file. – BrightEyed Aug 28 '15 at 00:24
  • Also, appending the .0 wasn't required for us. Thanks for the spelling fix btw, chucked the post up after a looooong night ;D – BrightEyed Aug 28 '15 at 00:26
  • Awesome, glad to hear the verification. I understand, I'm on my 3rd long day in a row now. (11, then 14 hours, today may be another 14 hours.) – austinian Aug 28 '15 at 17:41
  • 1
    Eeesh, living the IT dream :D – BrightEyed Aug 29 '15 at 02:07