6

I'm running lighttpd/1.4.28 (ssl) on Debian Squeeze. I just created a http://startssl.com certificate, I runs fine at all of my Browsers (Firefox, Chrome, Opera), but my users are reporting certificate-errors in Firefox. I already nailed it down to a failing of loading of the certificate chain:

Certificate at my Firefox: http://i.stack.imgur.com/moR5x.png
Certificate at others Firefox: http://i.stack.imgur.com/ZVoIu.png (Note the missing StartCOM-certificates here)

I followed this tutorial for embedding the certificate in my lighttpd: https://forum.startcom.org/viewtopic.php?t=719

The relevant parts of my lighttpd.conf look like this:

$SERVER["socket"] == ":443" {
        ssl.engine = "enable"
        ssl.ca-file = "/etc/lighttpd/certs/ca-bundle.pem"
        ssl.pemfile = "/etc/lighttpd/certs/www.bisaboard.crt"
}

ca-bundle.pem was created like this: cat ca.pem sub.class1.server.ca.pem > ca-bundle.pem
I grabbed the relevant files from here: http://www.startssl.com/certs/

www.bisaboard.crt was created like this: cat certificate.pem ssl.key > www.bisaboard.crt
Where certificate.pem is my StartSSL-Class1 Certificate and ssl.key my SSL-Root-Key.

Do you have any idea why the second Firefox does not correctly load the certificate-chain?

Md Mahbubur Rahman
  • 414
  • 2
  • 7
  • 15
TimWolla
  • 162
  • 1
  • 7

5 Answers5

3

Your webserver doesn't seem to present the intermediate certificates correctly, the reason it works in your own browser is probably because you've downloaded and installed them locally yourself.

Why don't you just download the ca bundle they already prepared for you at http://www.startssl.com/certs/ca-bundle.crt and use that for the ssl.ca-file option?

Mathias R. Jessen
  • 24,907
  • 4
  • 62
  • 95
  • I tested that one as well. It does not work. And only some firefoxes are affected, I also have reports with working SSL. Additionally ONLY Firefox is affected, no other browsers. Edit: The random-SSL-Checkers out there in the web tell me my cert. would be valid: http://www.sslshopper.com/ssl-checker.html#hostname=www.bisaboard.de – TimWolla Jan 03 '12 at 21:42
  • Funky stuff, my browser (Chrome 16 on OS X) doesn't recognize your issuer as trusted – Mathias R. Jessen Jan 03 '12 at 21:51
  • At my Chrome 16.0.912.63 on Ubuntu Linux it works fine. Strange thing. – TimWolla Jan 03 '12 at 22:02
  • Chain presentation looks good, see `openssl s_client -connect www.bisaboard.de:443 -showcerts`. @TimWolla Are you sure the failing browsers are properly trusting that StartCom root certificate? – Shane Madden Jan 03 '12 at 22:02
  • @ShaneMadden There are less StartCom certificates than at my firefox, but at least the root-certificate is there: http://media.bisaboard.de/ssl-trusted.png <- That screenshot comes from the same firefox as the Windows-Firefox above. – TimWolla Jan 03 '12 at 22:09
  • @TimWolla Is that the right certificate? Serial of `01`, thumbprint of `3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f`? – Shane Madden Jan 03 '12 at 22:18
  • The Serial and thumbprint match both. I just checked the certificate on that Windows-Firefox. – TimWolla Jan 03 '12 at 22:23
1

Firefox is notoriously stringent on getting the whole certificate chain verified, and it's likely you haven't specified all the certificates in the chain correctly. I recently had a similar issue with Firefox and a Comodo SSL certificate on Lighttpd, and the problem was that I did not list the chain in the ssl.ca-file correctly.

According to RFC 2246 the senders's certificate must come first and each following certificate must directly certify the one preceding it. I ended up having four certificates in the chain all the way up to the CA Root.

certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

Community
  • 1
Armin Sadeghi
  • 341
  • 2
  • 4
0

I had a problem with exactly similar behavior: some Firefoxes were complaining about missing chain, but not all. Adding a additional certificate chain parameter (and file that contained all the certificates one after another) to the server config seemed to help. I'm running Apache Traffic Server myself.

That solution is also what SSLhopper suggests in the link in the comments: http://www.sslshopper.com/ssl-checker.html#hostname=www.bisaboard.de

I don't know about lighttpd config, but probably there's an extra parameter to announce the chain file for the intermediate certificates.

Gnomet
  • 101
  • 3
  • Thanks for your answer. It didn't help though. The chain file is already properly included in my config and openssl on the command line properly recognizes the chain as well. The relevant line for the chain is just FYI: `ssl.ca-file = "/etc/lighttpd/certs/ca-bundle.pem"` – TimWolla Jan 29 '13 at 16:10
0

I had this same problem (using node.js) and the solution was to append the sub.class1.server.ca.pem file to the ssl.crt file.

Just copy the contents of sub.class1.server.ca.pem into ssl.crt making sure one is under the other with no space in between and it should work.

You can read more about it here.

slm
  • 7,355
  • 16
  • 54
  • 72
Marco Gabriel Godoy Lema
  • 101
  • 1
0

I ran in that issue after a certificate renewal yesterday. All my test devices/browsers worked fine with the renewed certificate, so I drove home.

Today I came into the office and half of our company/customers saw that browser security warning in their browsers.

Even with the same deployed Firefox ESR version here in the company?!

My solution was to use the correct valid intermediate certificate on the server.

Totally forgot the SHA1 problems StartCom acutally has.

Get the current class 1 domain validated SHA2 intermediate certificate (in my case): https://www.startssl.com/certs/sca.server1.crt, replace the old onesub.class1.server.ca.pem with it, restart the webserver (Apache on my end) and it'll work in all browsers.

synthor
  • 1