Resolved Let's Encrypt: Timeout during connect (likely firewall problem)

[hansitheking]

Server operating system version

Ubuntu 22.04.3 LTS

Plesk version and microupdate number

Obsidian Version 18.0.54 Update #4

Unfortunately, I've been having very severe problems getting new Let's Encrypt certificates for a good two months now. Sometimes it works, sometimes not. Sometimes only for the domain but not for the subdomain www. I have tried a lot. Firewall ports are open and not filtered. Redirect to from HTTP to HTTPS I have also disabled, then it usually works for the domain, but not, the subdomain www. I have already deleted the .well-known directory and created again. Also the .htaccess files have already "turned off" for getting the certificate. The whole thing is very similar to the description in this forum post. Here one of the errors:

Here is the exact error:

Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/2645646576.
Details:
Type: urn:ietf:params:acme:error:connection
Status: 400
Detail: IPv4-ADDRESS-SERVER: Fetching https://example.com/.well-known/acme-challenge/V7TKxrtvXElTn_6Ug-Ol_qSRxj6776efz1eANToQ: Timeout during connect (likely firewall problem)

Server-data:
Plesk Obsidian Version 18.0.54 Update #4
Ubuntu 22.04.3 LTS
Server with IPv4 and IPv6

Does anyone of you have an Idea?

 

[Peter Debik]

Please thoroughly check the DNS routing entries of the www subdomain. Are they present? Are they consistent in case there are AAAA an A records or multiple AAAA or A records? Check whether all of these routes are correct and all lead to the server. Also make sure that the subscription uses exactly the IP addresses that are set in DNS for your www subdomain.

 

[hansitheking]

Thank you @Peter Debik for your reply. I did a double check on all the DNS records and checked them with online tools. All domains and subdomains included in the certificate are directing correctly to the server IPv4 and IPv6. I continued with testing on several domains and see the following situation:

1. first attempt to get a certificate for (example.com and www.example.com) fails
2. second attempt to obtain a certificate with manual disabled HTTP > HTTPS redirection (via Plesk switch) is successful for the main domain (example.com) but not for the subdomain (www.example.com), This bug is also stated in this article: Unable to issue a Let's Encrypt certificate: The token file is either unreadable or does not have the read permission, but not yet fixed.
4. third attempt with the value (None) for preferred domain (instead of example.com) and with HTTP to HTTPS redirection still disabled is then successful for both domains (example.com and www.example.com).

In summary, so far, I can say: Plesk has problems issuing lets encrypt certificates when domain forwarding from (HTTP to HTTPS) is enabled and there are problems issuing certificates for the subdomain "www" when the preferred domain is set to "example.com" and not "None".

 

[Peter Debik]

Thank you for your explanation. I understand that you tried to issue a certificate for the www subdomain, but had instructed the webserver to not use the www subdomain. I can confirm that this poses an issue, because the token file that is needed to validate the www subdomain cannot be read if the web server has been told to not use the www subdomain. I am not sure whether this can be fixed server-side, though. I think you already found the best solution.

 

[trialotto]

@hansitheking (and @Peter Debik),

In essence, there is a question unanswered here : @hansitheking , do you use an external DNS provider?

Although the answer is relevant, the general comments to the issue are not dependent on the answer.


In general, it is correct to state that the SSLit and / or Let's Encrypt extensions have issues, being

1 - www subdomain is sometimes (but not often) not secured, when renewing the LE certificate,

2 - webmail subdomain is often (almost everytime) not secured, when renewing the LE certificate,

3 - succesfully renewed LE certificates cannot be assigned to the webmail subdomain via the Advanced Settings

and the above is a non-exhaustive summary of issues.


The fact is that there many explanations and causes for the issues encountered when renewing LE certificates.

The fact is ALSO that some of the most common issues are not related to Plesk or it's extensions.


Let's Encrypt has and has had some issues with connectivity and, as a result, there might have been issues at renewal time.

Let's Encrypt also has a limit on requests, which are translated into Plesk : one cannot continuously make renewal requests within a short interval.

Let's Encrypt also has some other issues and bugs that are still on the verge of being solved.


Nevertheless, there are also some known issues that are UNIQUE to Plesk and that can be considered to be a Plesk bug.

In essence, it is very likely that you have made to much attempts to renew the LE certificates ........ so, first TRY to wait for a couple of hours!

If I am not mistaken, then the 400 error should be gone in the error notification.


It still is very likely that you will get another error notification after renewing the LE certificate.

In that case, you might be helped by simply deleting the "order" - follow this KB : https://support.plesk.com/hc/en-us/articles/12377082364439


After that, it is still very likely that the www or webmail subdomain is not secured.

If that is the case, then please consider a workaround : first try to install a "wildcard" LE certificate ....... that should work flawlessly.


As a final remark, it should be duly noted that any solution or workaround is or can be temporary - most of the Plesk related bugs or issues with LE are often (but not always) "recycled" : they can (or even will) return.

I personally find it quite convenient (and more safe) to use the "wildcard" method and use external DNS ...... it has proven to be more robust over time, but it is not a final solution - specific issues seem to return.


I hope the above helps a bit.


Kind regards.....