Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Did you ever figure out what the issue was? –  Accipheran Jan 22 at 21:16
    
@Accipheran Unfortunatly no. I am running nginx instead of lighttpd by now. –  TimWolla Jan 23 at 0:18
    
haha, the server I'm getting the issue with is nginx. Think I'm just gonna use a godaddy cert instead, hopefully that fixes it. Thanks for the update! –  Accipheran Jan 23 at 15:34

4 Answers 4

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?

share|improve this answer
    
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: sslshopper.com/ssl-checker.html#hostname=www.bisaboard.de –  TimWolla Jan 3 '12 at 21:42
    
Funky stuff, my browser (Chrome 16 on OS X) doesn't recognize your issuer as trusted –  Mathias R. Jessen Jan 3 '12 at 21:51
    
At my Chrome 16.0.912.63 on Ubuntu Linux it works fine. Strange thing. –  TimWolla Jan 3 '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 3 '12 at 22:02
    
@ShaneMadden There are less StartCom certificates than at my firefox, but at least the root-certificate is there: media.bisaboard.de/ssl-trusted.png <- That screenshot comes from the same firefox as the Windows-Firefox above. –  TimWolla Jan 3 '12 at 22:09

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.

share|improve this answer

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.

share|improve this answer
    
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

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.