Skip to content


Fixing letsencrypt’s “expected xxx.pem to be a symlink”

Apparently, last time I migrated my server, I messed up my Let’s Encrypt configuration. Or maybe Let’s Encrypt changed its way of storing it. Anyway, renewing my certificates failed with this error:

expected /etc/letsencrypt/live/notepad.patheticcockroach.com/cert.pem to be a symlink
Renewal configuration file /etc/letsencrypt/renewal/notepad.patheticcockroach.com.conf is broken. Skipping.

Obviously, a file was supposed to be a symlink and it wasn’t. Which is strange, because I migrated just like the previous times, and a migration never caused that issue before. Anyway, I found a suggested solution that said to turn said .pem file into a symlink manually. Sounds a bit hackish to me.

I chose to just reissue new certificates for the same domain name. But if you do so, you must clean up properly, otherwise you’ll end up with new paths to your certificates, something like /etc/letsencrypt/live/yourdomain.com-0001/cert.pem, which would require you to also update your HTTP server configuration.

To clean up:

rm -rf /etc/letsencrypt/{live,renewal,archive}/{yourdomain.com,yourdomain.com.conf}

(source)
(NB: watch out, you should probably make a backup before running this)

Then you should be able to get a new certificate, under the same file and folder names, with the usual command:

certbot certonly --webroot -w /home/www/path -d yourdomain.com

Posted in security, servers, web development.


4 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Hanwu says

    Thanks, worked like a charm. In my case we had to adjust the apache2 conf as well, since we (for whatever mistake we made) multiple certs. We cleaned up with your tips.

  2. CertBotMadness says

    Yeeeah – that isn’t the issue. The problem is that there is a mismatch between the conf file name and directory defs vs. the website directory names in /archive and /live. For example, if the conf file is called www.sitename.com.conf and includes the same path naming for its defs (top of file), and the directories for that site in /live and /archive are called sitename.com (without the www., which can happen), then the update will fail with the “not a symlink” error because the paths don’t match. To fix it: delete www. from the conf filename, and open and manually edit the .conf file to get rid of the www. in the directory defs at the top – that is the origin of the problem. So, eliminate www and make sure the .conf directory filenames exactly match the directory names in /archive and /live. No reinstall needed. It is just a simple directory lookup error with a confusing error message from certbot. It should say “cannot find simlink at [path] defined in [site].conf file – check the path resolution” or something to that effect — not a red-herring message that says that a file isn’t a simlink (when it is and it’s just the paths that don’t match). But, I grant that reinstalling will also certainly fix it. You can also get rid of the other [webroot] junk in the .conf file (which appears when you use www in the setup]. It just needs directives for account = blah, authenticator = (usually apache), installer = (usually apache) and server = blah.letsencrypt.org, etc. Good luck!

  3. CertBotMadness says

    remove the http:// in my post – that was added by the post engine that turned the filenames into links

    • patheticcockroach says

      Yeah WordPress is annoying for this, just like most modern forum/comment systems… I edited those



Some HTML is OK

or, reply to this post via trackback.

Sorry about the CAPTCHA that requires JS. If you really don't want to enable JS and still want to comment, you can send me your comment via e-mail and I'll post it for you.

Please solve the CAPTCHA below in order to fight spamWordPress CAPTCHA