Mike, that log file /var/log/letsencrypt/letsencrypt.log is thousands of lines long.
Is there a way to clear that entire file via Nano commands?
Yes, see post number sixteen for the renewal config file
4 Likes
I scrolled right past that part. I also do not use the server plugins with certbot, so I'm less likely to be looking for them. Everyone uses webroot just like me, right? 
4 Likes
Usually the log file rolls over for each new certbot request. But yes they can get long which is why I suggested uploading it. You have to copy it to a .txt file first though. Value of that is it will show the nginx blocks as they are being changed by certbot.
Many times we can see the problem if you upload or post the entire nginx config. Run this command and upload the file or just paste the contents of upload.txt. Put 3 backticks before and after if pasting
sudo nginx -T >upload.txt
upper case T
I am signing off for nite but others may help else c u tmrw
2 Likes
upload.txt (138.6 KB)
Here is that file after running that command sudo nginx -T >upload.txt
thx
try adding this to the certbot renew command with value of say 10 as a test
--nginx-sleep-seconds NGINX_SLEEP_SECONDS
Number of seconds to wait for nginx configuration
changes to apply when reloading. (default: 1)
4 Likes
The --debug-challenges option might also help here to debug the issue. E.g., to see the actual nginx configuration with nginx -T at that exact moment with the challenge in place.
4 Likes
Mike, is this correct comamnd?
sudo certbot renew --dry-run --nginx-sleep-seconds 10 --cert-name help.hellobonafide.com
I get this error:
certbot: error: unrecognized arguments: --nginx-sleep-seconds 10
@Osiris
What command needs the flag --debug-challenges ?
1 Like
The certbot command when you try to issue or renew a cert.
1 Like
Yes, but, I just realized your version is too old to support it. It started with v1.7 back in Aug2020.
The --debug-challenges is a good idea as it also adds a sleep. Try
sudo certbot renew --dry-run --debug-challenges --cert-name help.hellobonafide.com
When it says "Challenges loaded. Press continue" just wait a few seconds before pressing enter.
If that still fails we can repeat that but do the nginx -T in a different window while that is paused.
That all said, were there any key changes since Mar31 when you last got a cert for help?
3 Likes
- No key changes were made known to me, but I will ask my greater team. I was just placed onto this task of "fixing the SSL" and my experience with certbot is very new
- I ran the command:
sudo certbot renew --dry-run --debug-challenges --cert-name help.hellobonafide.com
However, it did not actually pause for me at this stage. It waited 1 second, then continued on by itself.
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cleaning up challenges
Attempting to renew cert (help.hellobonafide.com) from /etc/letsencrypt/renewal/help.hellobonafide.com.conf produced an unexpected error: Failed authorization procedure. help.hellobonafide.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: 40.70.27.24: Invalid response from https://hellobonafide.com/pages/help-center: "<!DOCTYPE html>\n<html class=\"no-js\" lang=\"en\">\n <head><meta charset=\"utf-8\">\n <meta http-equiv=\"X-UA-Compatible\" content=\"IE". Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/help.hellobonafide.com/fullchain.pem (failure)
1 Like
That failure is strange. Not only is it redirecting to HTTPS but the hostname it redirects to is not for that server block. It "feels" to me like your older certbot isn't parsing something right. There have been many changes in nginx parsing since 0.31 and you could look to update that (see docs here)
But, without updating that you could try this command
sudo certbot certonly --webroot -w /var/www/html --dry-run -d help.hellobonafide.com
After changing your server block to look like below and reloading nginx
server {
listen 80;
server_name help.hellobonafide.com;
location /.well-known/acme-challenge/ {
root /var/www/html;
}
location / {
return 301 https://$host$request_uri;
}
}
The --webroot method doesn't parse your nginx conf and makes no changes to it. Certbot will place a file in the -w folder which nginx will return to the Let's Encrypt server because of the location for /.well-known/acme-challenge
If this test works you should be able to just remove --dry-run and do it again. It will update your renewal conf file to use this method for a renew which you could test with
sudo certbot renew --dry-run --cert-name help.helpbonafide.com
3 Likes
Mike, can you clarify what server block would change in my existing code?
server {
listen 443 ssl;
server_name help.hellobonafide.com;
ssl_certificate /etc/letsencrypt/live/help.hellobonafide.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/help.hellobonafide.com/privkey.pem; # managed by Certbot
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
location ~ ^/(hc/en-us/articles/360037951753-What-is-Bonafide-) {
return 301 $scheme://hellobonafide.com/pages/help-center?a=What-is-Bonafide---id--JEiQRnDaSeGGCQBqlVn3_w;
}
location ~ ^/(hc/en-us/articles/360050101394-I-have-a-Bonafide-subscription-How-can-I-add-an-additional-Bonafide-product-to-my-existing-subscription-) {
return 301 $scheme://hellobonafide.com/pages/help-center?a=I-have-a-Bonafide-subscription.-How-can-I-add-an-additional-Bonafide-product-to-my-existing-subsc$
}
location ~ ^/(hc/en-us/articles/360050626093-I-have-multiple-Bonafide-subscriptions-How-can-I-make-changes-to-one-and-not-the-other-) {
return 301 $scheme://hellobonafide.com/pages/help-center?a=I-have-multiple-Bonafide-subscriptions.-How-can-I-make-changes-to-one-and-not-the-other---id--KVX$
}
}
server {
if ($host = help.hellobonafide.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name help.hellobonafide.com;
return 404; # managed by Certbot
}
Hey Mike, my greater team has fixed this by "creating a manual run of the LetsEncrypt cert,".
I suppose we can close this out...
You would replace the above with my suggestion.
A manual method is a bad idea. Those cannot be automated so must be repeated every 60 days or so.
4 Likes
What does that mean?
Anyone who runs across this topic would benefit from a well documented solution.
3 Likes
@MikeMcQ
Okay understood on the manual. This task is being shifted out of my control now to new department, but will relay the message about manual.
@rg305
If I can obtain the "fix" I will post it here.
Thanks for all your help and time here
3 Likes
You should have that new department check the cert config. It is missing the intermediate chain. Often this is when someone uses cert.pem instead of fullchain.pem
See this cert test site
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.