SSL error with a newly signed cert?

Last night I literally spent hours figuring out an alleged issue with the certificate from StartCom. Of course the problem was entirely on my end, in the editor to be precise. But what happened?

I fetched ca-bundle.pem and entered it as ssl.ca-file. Furthermore I concatenated my private key used for the CSR and the signed cert I got from StartCom (excellent service in every respect) into a PEM file that I assigned in lighttpd using the ssl.pemfile directive. Then I tried to restart the server (shortened output for brevity):

# service lighttpd restart
Stopping web server: lighttpd.
Starting web server: lighttpd [...] (network.c.607) SSL: Private key does not match the certificate public key, [...]
 failed!

Wait! But I had just gotten the cert from the StartCom control panel, pasted it into my PEM file and did the same with the key.

Inspecting the certificate public key modulus and comparing it with the one from the private key brought a surprise:

# openssl rsa -modulus -noout -in domain.pem
unable to load Private Key
16986:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: ANY PRIVATE KEY

… uhm, that is essentially what lighttpd was telling me already. I looked at the old working PEM for another domain and saw no obvious differences there. So I decided to exchange the key and certificate positions and retry:

# openssl x509 -modulus -noout -in domain.pem
unable to load certificate
17095:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: TRUSTED CERTIFICATE

… I thought I’m onto something here.

Eventually I was sanity-checking some assumptions that the inspection inside Vim and my other editor on Windows seemed to support. Alright:

# grep '^-----' domain.pem
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

… opening the file in an editor again seemed to disprove the silly grep(1) output, until it dawned on me.

Of course, when I pasted the cert had created a new file. My editor was set to default to UTF-8 and thus must have prepended the BOM (byte order marker) to the file. However, every self-respecting editor is going to suppress that and instead show you some subtle piece of information in the status bar or so, telling you of the fact. Sure enough file(1) agreed with me:

# file key.pem
domain.pem: UTF-8 Unicode (with BOM) text

Removing the BOM was relatively easy (did it on the stored keys and certs, of course), but I wanted to verify upfront what file(1) would say. So I did:

# tail -c +4 key.pem|file -
/dev/stdin: PEM RSA private key

Fair enough. So I removed it on the actual file:

# tail -c +4 key.pem > key.pem
$ file key.pem
key.pem: PEM RSA private key

End of story. It works now:

# grep '^-----' domain.pem
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

// Oliver

PS: thanks to Eddy Nigg from StartCom for some pointers and questioning some of my assumptions.

This entry was posted in Administration, EN, IT Security, Linux, Software and tagged , , . Bookmark the permalink.

3 Responses to SSL error with a newly signed cert?

  1. Alex says:

    Nice research 😀 Cheers
    Sorry that I’ve read your article after found a solution myself.
    But I surprised, that ca-bundle.pem worked for you.
    I’d make it work after I cuted “—CRL BLABLA—” part (big part) of this file (lets call it bundle.pem after that)
    and got ssl.ca-file as sum of ca.pem and bundle.pem
    It doesn’t metter how, if it works. But ca-bundle.pem itself very big. And browser getting it every time, when checkin your cert. So you can save some bandwidth usin my method.

  2. Jim Somerville says:

    This is great! Finally solved an issue we were having with a private key text file (FromGoDaddy_generated-private-key.txt) from GoDaddy for a wildcard certificate.

  3. nathan says:

    this solved hours of time for me, thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *