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 [45.77.43.95]: "\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)

IMPORTANT NOTES:

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,
Rick

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,
Rick

1 Like

Hi @EAC

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

3 Likes

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,
Rick

2 Likes

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