PEM_read_bio_PrivateKey() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: ANY PRIVATE KEY)
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.
/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
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:
listen 443 default_server ssl;
ssl_protocols TLSv1.1 TLSv1.2;
# ssl_dhparam /etc/ssl/certs/dhparam.pem;
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.