Timeout renewing certificate on Plesk

My domain is: novalido.es

I have a Plesk server using the SSL it! plugin. On renewal of one of the certificates, on March 10th, it failed due to a timeout. Here it is the message:
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/86523214320.

Details:

Type: urn:ietf:params:acme:error:connection

Status: 400

Detail: Fetching https://cloud.novalido.es/.well-known/acme-challenge/oqfgLTuyJ6Lvn0HWTRM3ek2tBtio4GKsXJFfNYddT78 : Timeout during connect (likely firewall problem)

Server is CentOS Linux release 7.9.2009 (Core), running Plesk Version 18.0.41 Update #1
Nginx as proxy, Apache as backend. My hosting provider is IONOS.

I have manually check the URL and my server shows the challenge, so my guess is that it is a networking issue: firewall, failures, etc. It is not clear to me if it is on my side or in Let's Encrypt side.

I have also checked fail2ban logs to make sure it is not blocking access from Let's Encrypt.

Nginx logs does not show the request from Let's Encrypt server too.

I have checked the status on Let's Encrypt and it shows all systems are up and running, but there was a maintenance activity yesterday.

1 Like

Is your server listening on port 80 (http)? It is. It just takes a very long time to answer, occasionally.

I don't know what to attribute this delay to, if your server or your nameservers, or broken routing, DDoS on the internet infrastructure, or many other things.

I think you should just try again after a few hours (your client should, automatically).

3 Likes

The server is listening in port 80 and 443. In addition, if you copy and paste the failed URL in your browser, you can reach the file.

The problem is persisting, I have just received another report about timeouts trying to reach the server for renewing the certificate.

I had a closer look to the new report (here https://acme-v02.api.letsencrypt.org/acme/authz-v3/86877060220) and it is trying to connect to IPv6 addresses, but the server is not listening on them. I will remove the AAAA record and expect it will solve the issue.

Regards.

1 Like

Well, it should start to.

3 Likes

I have also check if there is a firewall problem, but it isn't. See result of nmap from a different server outside of the cloud.novalido.es server.

[root@server ~]# nmap -p 443 cloud.novalido.es
Starting Nmap 6.40 ( http://nmap.org ) at 2022-03-12 18:14 CET
Nmap scan report for cloud.novalido.es (87.106.228.251)
Host is up (0.035s latency).
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

[root@server ~]# nmap -p 80 cloud.novalido.es
Starting Nmap 6.40 ( http://nmap.org ) at 2022-03-12 18:14 CET
Nmap scan report for cloud.novalido.es (87.106.228.251)
Host is up (0.036s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.61 seconds
1 Like

@miceno I see your server is sending out a cert created today. It looks like your problem was fixed. Do you still need help?

subject= /CN=cloud.novalido.es
issuer= /C=US/O=Let's Encrypt/CN=R3
notBefore=Mar 12 13:02:10 2022 GMT
notAfter=Jun 10 13:02:09 2022 GMT
serial=03FBE4D445EE708C92F14713D238DB10B2C7
5 Likes

I can connect to your challenge file just fine

~ $ time curl -iL http://cloud.novalido.es/.well-known/acme-challenge/oqfgLTuyJ6Lvn0HWTRM3ek2tBtio4GKsXJFfNYddT78
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 12 Mar 2022 17:31:42 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://cloud.novalido.es/.well-known/acme-challenge/oqfgLTuyJ6Lvn0HWTRM3ek2tBtio4GKsXJFfNYddT78

HTTP/2 200
server: nginx
date: Sat, 12 Mar 2022 17:31:42 GMT
content-type: text/plain
content-length: 87
last-modified: Fri, 11 Mar 2022 10:16:31 GMT
etag: "622b217f-57"
x-powered-by: PleskLin
accept-ranges: bytes

oqfgLTuyJ6Lvn0HWTRM3ek2tBtio4GKsXJFfNYddT78.dctW5haMOp-ygrmfXGju61rI9hnpbUKA93S-jB81fvY
real    0m0.600s
user    0m0.136s
sys     0m0.021s
~ $
3 Likes

Thank you all!

I left it to rest for a couple of days and I finally got the certificate renewed.

I think the issue was related to IPv6, since the hosting provider does not allow an IPv6 but I have created an AAAA record on DNS.

2 Likes

Indeed, if you have an AAAA record the validation bots will try to validate over IPv6 and they won't always try IPv4.

3 Likes

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