Certificate renewal returns "unauthorized"


I use letsencrypt-auto command to renew my existing certificate on a monthly basis. It worked over a year without any problems but it seems stopped working since Dec 2018. The last successful renewal was on Nov 2, 2018. I changed nothing in the configuration of my system so I don’t know why it doesn’t work anymore.

My domain is: rapidm2102.ddns.net

I ran this command:
./letsencrypt-auto -d rapidm2102.ddns.net --redirect -m xxx@gmail.com --agree-tos --renew-by-default

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for rapidm2102.ddns.net
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. rapidm2102.ddns.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://rapidm2102.ddns.net/.well-known/acme-challenge/FEKy5mPK4S6l9VSJ8z3X8dUZkYPpbyhwE2Kh-v3ANEw []: 404


My web server is (include version): apache 2.4

The operating system my web server runs on is (include version): Raspbian GNU/Linux 8 (jessie)

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): Remote Desktop Connection

My certificate is valid until Jan 31, 2019. Any help before this date would be appreciated.



Could you please try to place a file under $document_root/.well-known/acme-challenge/ ?

Please place the file without extension, and make an random name.

Then please share us the link and try to see if that file showed up…

Thank you

Thank you for your help!

So I assume my $document_root is /var/www on my Raspberry PI. Should there be a path
/var/www/.well-known/acme-challenge or do I need to create this path?

My /var/www directory doesn’t contain a .well-known/acme-challenge path.


Hi @demu2102

then create the path. It's only to test if you know the correct path.

If this is the correct path, then use

./letsencrypt-auto run -a webroot -i apache -w /var/www -d rapidm2102.ddns.net

to create the certificate.

It's because of the TLS-SNI-01 validation method deprecation. The previous method that Certbot used to prove your control over your domain name used port 443. But this method has a security problem in some shared hosting environments and Let's Encrypt is going to completely discontinue it in mid-February.

As a result, Certbot changed its default behavior in advance of this change so that it uses a different method (HTTP-01 on port 80). Apparently this isn't working properly in your configuration, while the old method did. I'm still trying to figure out why this is happening for some people, because the new method works properly for most people in most configurations, but apparently not all.

The -a webroot suggestion from @JuergenAuer is a good option if it works and you don't want to spend a long time diving into a potential Certbot bug related to Apache configuration parsing. :slight_smile: (but if you do, please let me know!)

Thanks for all the good hints. The reason was that port 80 was not open for my domain as I used port 443 before. That was probable the reason for the “unauthorized” response. I opened port 80 to my domain and now it works perfectly.

Thanks to all who replied to the post!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.