OpenSSL: get_name: no start line?

As part of my DIY mail server project, the other day I put a POP3 server on that box – solid-pop3d if you want to know –, and since that server doesn't have SSL built in, I configured stunnel to provide that, re-using a certificate I get for mail.tfiu.de's https server from letsencrypt. Trivial configuration:

[spop3d]
accept=995
connect=110
cert=/etc/stunnel/mail.pem

And bang!, an error message from stunnel:

[ ] Loading private key from file: /etc/stunnel/mail.pem
[!] error queue: 140B0009: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
[!] SSL_CTX_use_PrivateKey_file: 909006C: error:0909006C:PEM routines:get_name:no start line

One of my least favourite pastimes is figuring out cryptic OpenSSL error messages, and so I immediately fed this to $SEARCH_ENGINE. The responses were, let's say, lacking rigour, and so I thought I might use this blog to give future message googlers an explanation of what the problem was in my case.

What OpenSSL was saying here simply was: there's no private key in the PEM.

Where would the fun be if OpenSSL had said that itself?

In case this doesn't immediately tell you how to fix things: “PEM files” in today's computing [1] are typically bundles of a “key” (that's the pair of public and secret key in sensible language), a “certificate” (that's a signed public key in sensible language), and possibly intermediate certificates that user agents may need to figure out that the signature on the certificate is any good, based on what certificate authorities they trust.

All these things almost always come in base64 encoded ASCII these days (that's the actual meaning of “PEM“), which is nice because you can create your “PEM file” with cat if you've got the other parts. For instance, in my dealings with letsencrypt, I'm creating the key using:

openssl genrsa 4096 > $SERVERNAME.key

Then I build a certificiate signing request in some way that's immaterial here, and finally call the great acme-tiny something like:

acme-tiny --account-key ./account.key --csr ./"$SERVERNAME".csr \
        --acme-dir /var/www/acme-challenge\
         > ./"$SERVERNAME".crt

Letsencrypt also hands out the the intermediate certificates at a well-known URI, so I pull that, too:

curl https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem \
        > intermediate.pem

With that, all I have to do to make the “PEM file” is:

cat $SERVERNAME.crt intermediate.pem > $SERVERNAME.pem  # not

That was basically what I had in my certificate updating script, and that is what caused the error in my case. Spot it? Right, I failed to cat the key file in. I should have written:

cat $SERVERNAME.key $SERVERNAME.crt intermediate.pem > $SERVERNAME.pem

So – if you're seeing this error message, while I can't say why your key pair is missing in the PEM, I'd strongly suspect it is. Diagnosis: look for

-----BEGIN RSA PRIVATE KEY-----

somewhere in the file (and make sure all the dashes are present if you see something that looks like that and you're still seeing the odd OpenSSL message).

Zitiert in: A Mail Server on Debian