Certificate renew failed, invalid response

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: exploreabroad.club

I ran this command: # /usr/bin/letsencrypt renew

It produced this output:
[root@exploreabroad nginx]# /usr/bin/letsencrypt renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/exploreabroad.club.conf

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for exploreabroad.club
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (exploreabroad.club) from /etc/letsencrypt/renewal/exploreabroad.club.conf produced an unexpected error: Failed authorization procedure. exploreabroad.club (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://exploreabroad.club/.well-known/acme-challenge/4P8jwdq93-UywycIRaEK_gGdLQFi3zf8PdaQKkDTcTw []: "\n<html lang=“en”>\n \n <meta charset=“utf-8”>\n <meta http-equiv=“X-UA-Compatible” content=“I”. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/exploreabroad.club/fullchain.pem (failure)

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

Running post-hook command: systemctl reload nginx
1 renew failure(s), 0 parse failure(s)


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

The operating system my web server runs on is (include version):
CentOS Linux release 7.3.1611 (Core)

My hosting provider, if applicable, is: Vultr

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.20.0

1 Like

Do you have different document roots for the HTTP and the HTTPS virtualhost configuration? The challenge might have been properly installed into the document-root of the HTTP, but due to the permanent redirection to HTTPS it is not visible through that protocol.

1 Like

Hi @bruncsak, thank you for looking into this problem! I used the same document root for HTTP and HTTPS. My ngxin.conf:

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name exploreabroad.club;
root /www/eac/public;
index index.php index.html index.htm;
client_max_body_size 100M;

if ($scheme != “https”){
return 301 https://$host$request_uri;
} # managed by Certbot

I was able to read a file like “https://exploreabroad.club/.well-known/acme-challenge/LFYMIDdmhwQUy3mi4PSx4X-IiBxHszE6UeLPowARnro” through the browser.

Before I hosted my web application in a machine provided by another Cloud company and I was able to renew the certificate. However, I ran into the problem here while I moved it to a new machine with a different IP by Vultra.
Not sure if it that caused the problem?

Thanks a lot,

1 Like

Having different IP address due to machine move means DNS change. Old DNS information may be cached in different resolver caches. You may want to retry the certificate renewal.

1 Like

Thank you @bruncsak. I tried renewing the certificate serval times and still ran into the same issue. And I moved the web application to a new server about 3 months ago. Have you got any ideas that I can further debug this issue?

Thanks a lot,

1 Like


what's the webroot used in your certbot configuration file?


Hi @JuergenAuer, you are right! The certbot configuration file still used the old webroot “/home/eac/public”, and this is the root cause!

The certificate renew is successful after I correct the the webroot in the configuration file.

Thank you so much!!

Best Regards,


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