I am wondering if someone could help me with the same problem. I have looked at this thread, but it’s not helping me to resolve my issue. I have the same problem that the last time I did this I ran one command and it worked perfectly; now, I’m getting all kinds of errors.
What I used to do was ./letsencrypt-auto renew
My web servers are nodejs servers.
I can reach the server using http.
I see a lot of stuff in here about the /.well-known directory. The only place I can find a .well-known directory is in /etc/letsencrypt/live
If I put a file in there and try to reach it from the browser it doesn’t work, but that never would have worked.
I’m getting the same errors that I see other people talking about: (used certbot-auto in this example, but it’s the same problem with both commands.)
ubuntu@ip-:~/certbot$ ./certbot-auto renew
Requesting root privileges to run certbot…
/home/ubuntu/.local/share/letsencrypt/bin/letsencrypt renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for myDomain.com
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (myDomain.com-0001) from /etc/letsencrypt/renewal/myDomain.com-0001.conf produced an unexpected error: Failed authorization procedure. myDomain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://myDomain.com/.well-known/acme-challenge/43tD2TJZKjE7HhucZ9LMwRtO8DBOoEutTnjoxk0xA9g: "
I split this into a new topic because the underlying reason is not necessarily the same as the other person’s problem in the original thread.
Do you remember what command you ran to obtain your certificate in the first place? You apparently used --webroot (or chose it from a menu) and then gave it a directory where it could create files that would be publicly visible. Yet that directory apparently no longer has that property. Can you recall how Certbot could have created files that would have been served by the web server?
.well-known should definitely not be in /etc/letsencrypt/live; there’s no chance that that would be useful.
So sorry, I do not remember the original command. This is a good time to emphasize, again, that this has been working just fine for renewal after renewal. No idea what is going on, or could have changed.
As you say, having .well-known where it is is clearly not useful. I created a .well-known/acme-challenge in the root of my server, and put a file there. I can get to it from the web, using (I see no reason to obscure the domain name, actually) http://www.holacomm.com/.well-known/acme-challenge/test.html.
However, even at that, I am getting a failure from letsencrypt-auto renew.
Requesting root privileges to run certbot…
/home/ubuntu/.local/share/letsencrypt/bin/letsencrypt certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Huh, it would be fascinating to see what commands or situations produced this result. I have no idea how that happened.
Maybe you should run
history | grep letsencrypt
just in case you still have anything relevant in your command history that might account for it. (This isn’t necessary in order to fix the problem, just for curiosity.)
So, you may want to get rid of whichever of these two certificate lineages you’re not using. It’s not usually harmful to have an extra one, but it may be confusing.
These two files should be edited to change the paths in the [[webroot_map]] section to point at your real web server content root — not /etc/letsencrypt/live and almost certainly not /home/ubuntu either. Then your ./letsencrypt-auto renew command should work fine.
I have a ton of letsencrypt commands, but they are all from me trying to solve this problem today. I created this thing months ago, so no way that command is still around. I know there are log files somewhere. If it’s in there, I can send it to you.
Can you help me understand what directory I need to use? I have 2 servers running. One is an http server (port 80) running in one directory (so http://www.holacomm.com) and the other is the https server for which I need these keys (port 443) running in a different directory. (That is, there are nodejs scripts in these 2 different directories which create these web servers.)
So which one does the webroot-map need to see? I would have thought it was the https server directory, but so much of this conversation is about using http to do things, that maybe it’s that one. Can you clarify?
Edit: Note that in configurations where HTTP redirects to HTTPS, the certificate authority will follow the redirect, so it will be the HTTPS one. But in cases where they’re distinct, like you’re current site, it’s the HTTP one.
Cool. Thanks. I think this all worked. I’m pasting the output here for you to scan, just because there is some message about it being unable to clean up the challenge directory. But as long as there is that success message at the end I’m happy. As long as you don’t tell me to worry about anything else.
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for holacomm.com
Waiting for verification…
Cleaning up challenges
Unable to clean up challenge directory /home/ubuntu/webIF/.well-known/acme-challenge
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/holacomm.com-0001/fullchain.pem
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for holacomm.com
http-01 challenge for www.holacomm.com
Waiting for verification…
Cleaning up challenges
Unable to clean up challenge directory /home/ubuntu/webIF/.well-known/acme-challenge
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/holacomm.com/fullchain.pem
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/holacomm.com-0001/fullchain.pem (success)
/etc/letsencrypt/live/holacomm.com/fullchain.pem (success)
For the “deployed without reload”, this a warning that Certbot did not restart your web server (as in the server application, like nodejs). Therefore, your web server may not notice the existence of the new certificate until it gets restarted somehow.
If you’re interested in configuring Certbot to restart the web server when a certificate is renewed, it’s possible to do that too.
