Issue with certbot renew and mail

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: certbot renew --renew-hook “service nginx reload” --renew-hook “service postfix reload” --renew-hook “service dovecot restart”

It produced this output:

Processing /etc/letsencrypt/renewal/

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
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:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from “\r\n404 Not Found\r\n<body bgcolor=“white”>\r\n

404 Not Found

”. Skipping.

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

1 renew failure(s), 0 parse failure(s)


My web server is (include version): nginx/1.14.0

The operating system my web server runs on is (include version): Ununto 18.04

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


I believe you used the wrong hook....
If you want to reload all services after successful renewal, you should use post-hook for renewal....

Thank you

Firstly, I applaud you for even trying --renew-hook multiple times (had never thought of doing that).
Has this worked in the past?

@rg305 Yea, you can add as many renew-hook’s as you need:

1 Like

@stevenzhu --renew-hook only runs on a successful renewal. If I used post-hook it would reboot nginx every time the command is run, whether it attempts a renewal or not:

1 Like

Please show:
cerbot --version
certbot certificates
then each of the corresponding certificate renewal conf files:
[start with the one that covers “mail.gossip…”]

I also double checked the DNS just to be sure, it does have an A-record configured, and nothing has changed with the config since the initial application.

Version: certbot 0.26.1

Found the following certs:
Certificate Name:
Expiry Date: 2018-12-05 15:50:41+00:00 (INVALID: EXPIRED)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/

It’s weird this alone worked:

certbot --nginx certonly -n -d

but the multi-domain is still throwing a 404 \ can’t auth with

certbot renew

certbot --nginx certonly -n -d
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for
Waiting for verification…
Cleaning up challenges


  • Congratulations! Your certificate and chain have been saved at:
    Your key file has been saved at:
    Your cert will expire on 2019-03-10. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    “certbot renew”

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt:
    Donating to EFF:

Can you also show the renewal configs?:

List them:
ls -l /etc/letsencrypt/renewal/*.conf
Then show them:
less /etc/letsencrypt/renewal/{whatever-your-files-are-named}.conf

Here is the list (there’s 2 additional now from testing the mail, and having to get the site back up while trying to debug)

-rw-r--r-- 1 root root  577 Dec 10 19:42 /etc/letsencrypt/renewal/ 
-rw-r--r-- 1 root root 1004 Sep  6 16:50 /etc/letsencrypt/renewal/
-rw-r--r-- 1 root root  577 Dec 10 23:54 /etc/letsencrypt/renewal/

And here’s the config of the one having renewal issues ( I can post the config of the ones I just created to get the site back up as well if it will help:

# renew_before_expiry = 30 days
version = 0.26.1
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

# Options used in the renewal process
account = b24b626a560b41212e7d8c38cd9d63a0
rsa_key_size = 2048
authenticator = webroot
webroot_path = /var/www/,
server =
[[webroot_map]] = /var/www/ = /var/www/ = /var/www/ = /var/www/ = /var/www/ = /var/www/

As you can see, they all used the same webroot when they were issued:

But do they all still use that same (document)root?
Please show:
grep -Eri 'root|server_name|server_alias|listen' /etc/nginx/

Ahh I think that found it for me TY very much, I didn’t re-list the names in the nginx config for the mail subdomains when I re-wrote the server configuration after the cert was applied for, since I wasn’t running a reverse proxy on the mail server.

/etc/nginx/fastcgi.conf:fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
/etc/nginx/fastcgi.conf:fastcgi_param  DOCUMENT_ROOT      $document_root;
/etc/nginx/fastcgi.conf:fastcgi_param  SERVER_NAME        $server_name;
/etc/nginx/scgi_params:scgi_param  DOCUMENT_ROOT      $document_root;
/etc/nginx/scgi_params:scgi_param  SERVER_NAME        $server_name;
/etc/nginx/fastcgi_params:fastcgi_param  DOCUMENT_ROOT      $document_root;
/etc/nginx/fastcgi_params:fastcgi_param  SERVER_NAME        $server_name;
/etc/nginx/nginx.conf:  # server_names_hash_bucket_size 64;
/etc/nginx/nginx.conf:  # server_name_in_redirect off;
/etc/nginx/nginx.conf:#         listen     localhost:110;
/etc/nginx/nginx.conf:#         listen     localhost:143;
/etc/nginx/uwsgi_params:uwsgi_param  DOCUMENT_ROOT      $document_root;
/etc/nginx/uwsgi_params:uwsgi_param  SERVER_NAME        $server_name;
/etc/nginx/sites-available/default:     listen 80 default_server;
/etc/nginx/sites-available/default:     listen [::]:80 default_server;
/etc/nginx/sites-available/default:     # listen 443 ssl default_server;
/etc/nginx/sites-available/default:     # listen [::]:443 ssl default_server;
/etc/nginx/sites-available/default:     root /var/www/html;
/etc/nginx/sites-available/default:     server_name _;
/etc/nginx/sites-available/default:     # deny access to .htaccess files, if Apache's document root
/etc/nginx/sites-available/ server_name;
/etc/nginx/sites-available/ root /var/www/;
/etc/nginx/sites-available/ listen 80;
/etc/nginx/sites-available/ listen 443 ssl;

Gunna test out a fresh build that I think will fix the issue.

From that I see:

     root /var/www/;

     server_name _;
     root /var/www/html;

So, the only names that are using the document root that matches the webroot are:

All other names are grabbed by the default to /var/www/html

I think this can be fixed in the /etc/letsencrypt/renewal/*.conf files, in the [[webroot_map]] section.

Try changing:
[[webroot_map]] = /var/www/ = /var/www/ = /var/www/ = /var/www/ = /var/www/ = /var/www/

[[webroot_map]] = /var/www/html = /var/www/ = /var/www/html = /var/www/html = /var/www/html = /var/www/

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