Home

PEM_read_bio_PrivateKey() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: ANY PRIVATE KEY)

Details
Written by: J Grant Forrest
Category: Software and Coding
Hits: 16033
Tweet
Share

I have an Ubuntu 20.04 instance that I manage on behalf of a client. They recently upgraded from 18.04 and in the process, a TLS certificate issued by LetsEncrypt failed to renew.

It was a little complicated as another company had managed the migration, and there was evidence that they'd taken a different path to getting the TLS cert working, rather than use CertBot, which had been used initially.

The webserver is Nginx rather than Apache so I had to do some research to understand how to get CertBot to re-issue the cert. I followed this guide and all went well, with CertBot reporting that my cert installed successfully, and I could visit the domain(s) on https with no errors. However, I subsequently re-started Nginx and my sites broke.

In my /nginx/sites-available/site config, I had references to the original cert that hadn't been updated by CertBot. My new cert had been generated in /etc/letsencrypt/live/site but the Nginx server config was wrong.

I spent a while trying various configurations but was met persistently with this error:
nginx: [emerg] cannot load certificate key "/etc/letsencrypt/live/domain.com/fullchain.pem": PEM_read_bio_PrivateKey() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: ANY PRIVATE KEY)

I'm not sure what the underlying cause was - I suspect it was some mis-match from the previous configuration but in the end, I found this post that has a fairly comprehensive example that included paths to the *.pem files that I had in my /etc/letsencrypt/live path.

This config is slightly at odds with the CertBot docs. In the screen shot below, you can see that they advise different naming conventions:

 

In the end, what worked for me was the following Nginx server block:

server_name domain.com;
listen 443 default_server ssl;

ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
# ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

I had to comment out ssl_dhparam as the path was invalid on my client's server.

I'm posting as it's clear that Nginx is a bit picky about the setup, but there may be other legacy cert issues on this server that made life more complicated than it should have been.