Failed authorization procedure urn:acme:error:unauthorized

Hi, my SSL suddenly (and without my interference) stopped working. It has been working fine for the past few months since I set it up. I’ve spent the day googling and trying to find a solution, but I’m not sure I even understand what the problem is (I haven’t done backend stuff for a very long time). I would appreciate any help.

I’ve checked that .well-known is chmod 755, and I tried creating a folder called acme-challenge (also 755) and adding a test file to it, but cannot access it through my browser. (file is “test” without any extension).

My domain is:

I ran this command: sudo certbot-auto renew --dry-run

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from "

404 Not Found

404 Not Found

", (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from " 404 Not Found

404 Not Found

". Skipping. ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)
1 renew failure(s), 0 parse failure(s)


My web server is (include version): Nginx 1.4.6

The operating system my web server runs on is (include version): Ubuntu 14.04.5

My hosting provider, if applicable, is: Digital Ocean for the server, goDaddy for the domain

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): no

This is my “sites-enabled”:

You could try the solution from 404 on .well-known/acme-challenge/

In that post, the location for the static .well-known directory was changed to this. Alter your root path accordingly.

location ~ /.well-known {
allow all;
root /usr/share/nginx/html;


When I go to the IP-address, the test page works, but when I use my domain, I get the same “Your connection is not private” message.

Edit: to be clear, the sites-enabled file I showed is the /stxclock, not /default… Does that matter?

That browser warning is due to an expired certificate, which is the underlying problem that you're trying to solve with this renewal.

As a special case, the Let's Encrypt CA validator does not check certificate validity when connecting to your site to prove your control of the domain name, if it was redirected from HTTP to HTTPS by your web server. That is, if the CA comes to check and gets 301 redirected to but that resource has some kind of certificate error (like the expired certificate in this case), that's still OK and the Let's Encrypt validator will ignore that certificate error and just check that the content of the file is correct.

That in turn means that for debugging purposes, you should probably tell your browser to temporarily accept the expired certificate, and then see if the test page still works. That will more correctly reproduce what the CA will see when it comes to do the authorization process. However, it should be temporary rather than permanent so that you can later check what other users will see when they visit your site with a normal web browser. :slight_smile:


Ok, When I now visit in Safari, it actually works. However, I am still getting the same error message that I posted at the top (when I run “sudo certbot-auto renew --dry-run”. Anyone know what to try next?

I really hope someone can guide me in the right direction. I short, the acme-challeng/test works when I access it through Safari (it gets blocked by Chrome), but the actual test when I run certbot-auto renew --dry-run fails every time due to “the client lacks sufficient authorization”.

Hi @leBoer,

You are currently serving an expired certificate so getting blocked is what you should expect, I don't know what Safari does but it should block the access too.

Are you sure the renewal conf has the same document root used by your nginx conf?. I mean, you said you have put a test file inside .well-known/acme-challenge/ and it works, so if you have put that file for example on /var/www/.well-known/acme-challenge/test then your document root is /var/www/ and this path should be the same in the renewal conf for your domain that should be here /etc/letsencrypt/renewal/yourdomain.conf and in that file you should double check that the path of the document root for your domain is the same you are using right now.


Hi @sahsanu,

Thanks for your answer. I don’t actually have a /var/www… It’s been a while since I set up this server, but perhaps it’s because I run on Django and Gunicorn?

Hi @leBoer,

/var/www/ was just an example, what I mean, you created a test file here /some/path/.well-known/acme-challenge/test so /some/path/ is your document root. Do you have /some/path/ in the renewal conf file /etc/letsencrypt/renewal/yourdomain.conf ?


Hi @sahsanu,

This is what my file reads:

@leBoer, ok, so the renew is trying to use /home/christian/stxclock as the document root, the test file that is reachable using where is located in your hard disk? it should be located in /home/christian/stxclock/.well-known/acme-challenge/test. If the test file is there then the renew should work, if it isn’t there then your document root is not the same as is in the renewal conf and you should edit this file to correct the document root for your domains so the renew command could use the right one.

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