Unable to renew certificate using certbot - 404 for HTTP-01 challenge request


#1

My LetsEncrypt certificate expired, and unfortunately I have HSTS enabled, so when certbot creates a couple temporary files and then tries to access them via http it’s unable to do so.

Is there some other action I can take to renew my certificate without using certbot? It’s frustrating that they’d make it rely on accessing some files insecurely via http in order to renew the certificate. As I said I have HSTS enabled, and I also configured nginx to redirect all http traffic to https.

I’m using DigitalOcean running Ubuntu 16.04. Here’s the output of trying to run ./certbot-auto renew.

root@ghost-1gb-nyc3-01-my-blog:/opt# ./certbot-auto renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/grantwinney.com.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for grantwinney.com
http-01 challenge for www.grantwinney.com
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/ghost/.well-known/acme-challenge
Attempting to renew cert from /etc/letsencrypt/renewal/grantwinney.com.conf produced an unexpected error: Failed authorization procedure. grantwinney.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://grantwinney.com/.well-known/acme-challenge/bzfZnECf_zXY1TA9TK2ZqVZrzOOjaHnpN4yclEtFhgA: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>", www.grantwinney.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.grantwinney.com/.well-known/acme-challenge/SkkeIZHYF3F9kelPA3Lcl5GAgcwONo3plSpSYTOXXRw: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>". Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/grantwinney.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: grantwinney.com
   Type:   unauthorized
   Detail: Invalid response from
   http://grantwinney.com/.well-known/acme-challenge/bzfZnECf_zXY1TA9TK2ZqVZrzOOjaHnpN4yclEtFhgA:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   Domain: www.grantwinney.com
   Type:   unauthorized
   Detail: Invalid response from
   http://www.grantwinney.com/.well-known/acme-challenge/SkkeIZHYF3F9kelPA3Lcl5GAgcwONo3plSpSYTOXXRw:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

#2

Hi @grantwinney, sorry to hear you’re having trouble renewing your certs!

I think this interpretation of the root cause is slightly off. Based on the output shared above it looks like Certbot tells Boulder (the Let’s Encrypt server-side component of the CA) to perform the validation requests against your domain for the /.well-known/acme-challenge/ file, but Boulder gets a 404 response for the requests! Your webserver doesn’t give back the validation files to prove to Let’s Encrypt you control the domain.

I think it isn’t an HSTS problem for a few reasons;

  1. The HTTP-01 challenge is an HTTP request, not HTTPS
  2. If it were HSTS based, the connection would fail before a 404 was returned by the server.
  3. Boulder doesn’t honour HSTS at all! We specifically ignore it to avoid this problem :slight_smile:

Unfortunately I’m not especially well versed at debugging Apache/Nginx and Certbot for HTTP-01 but lots of other folks are. I’m going to update the title of this thread slightly and hopefully someone can help you find the true root cause.

Thanks!


#3

Thanks for the reply @cpu, and for updating the title for accuracy!

“Boulder doesn’t honour HSTS at all! We specifically ignore it to avoid this problem”

That’s good to know. I kinda figured this could be an issue for a lot of people.

It’s entirely possible I’m misusing/abusing terminology here, and there are definitely gaping holes in my knowledge of how all this stuff works. It just seems like a chicken and egg problem to me, where boulder needs to access the challenge files via http to get things working again, but due to my setup and expired cert that access is not possible. Since HSTS isn’t honored though, maybe it’s an issue of reconfiguring my nginx file to allow http requests…

Anyway, thanks again. I’ll hang out patiently. :slight_smile:


#4

Okay, yeah I’ve got misunderstandings of how HSTS works. I figured that once it was enabled then normal http was inaccessible. I see now that it’s more of a suggestion to the browser rather than a hard and fast rule.

I came across a post that shows how to view the site anyway in chrome, by telling it to ignore HSTS.
How To Bypass Chrome’s HSTS Warnings

Now I’ve created the .well-known/acme-challenge directory myself and thrown an empty test.txt file in there, and when I try accessing it from the browser I get a 404 too.
https://grantwinney.com/.well-known/acme-challenge/test.txt


Figured it out! :sweat_smile:

The last section of my nginx config file, for listening to 443, had a small blurb about where to direct requests for .well-known:

location ~ ^/.well-known {
    root /var/www;
}

I had to fix it to point to the correct directory. Made the change and reloaded nginx, then the certificate renewal worked just fine.

location ~ ^/.well-known {
    root /var/www/ghost;
}

Renewal suddenly stopped working (http-01)
#5

Great! I’m glad to hear you were able to figure it out!! :tada:


#6

Thanks again for the help. It’s great these forums are here. Sometimes all you need is someone to bounce a few ideas off of to get the wheels turning again.


#7

FYI: That should be included in the port 80 listening section as well.


#8

Thanks @rg305. I’ll double-check that.


closed #9

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