Issue Lets Encrypt - error in certificate renew process

[Nextgen-Networks]

Server operating system version

Ubuntu 20.04.6 LTS

Plesk version and microupdate number

Plesk Obsidian Version 18.0.56 Update #4

Hello Plesk users and Plesk Team,

I face a strange situation since a couple of days.
Existing Lets Encrypt certificates can't be renewed (was working for 2 years).

I've tried several checks to assure everything on server and domain side is configured properly.
... and left confused about the situation.

This is the error message I was confronted with::

SSL/TLS-Zertifikat konnte für myDomain.TLD nicht ausgestellt werden.
Details:
Let's Encrypt-SSL/TLS-Zertifikat konnte nicht ausgestellt werden für myDomain.TLD. Die Autorisierung dieser Domain ist fehlgeschlagen.
Details
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/UID.

Details:

Type: urn:ietfarams:acme:error:connection

Status: 400

Detail: 89.22.113.48: Fetching https://myDomain.TLD/.well-known/acme-challenge/U9dyxjn2Y-qlMWC01CnDkeu_FIVFgcy1CDp35HqrjUE: Timeout during connect (likely firewall problem)

Then wrote a short script to verify the external availability of that acme-challenge file:


Looks good ...

Next tried to renew the certificate with disabled firewall and web-application firewall.
Result is still the same - no renew possible.

Anyone else wit the same situation or preferred: With a solution? :-D

 

[Nextgen-Networks]

hmm - can't change the misleading topic/subject anymore ...
Should be: Lets Encrypt - error in certificate renew process

 

[Peter Debik]

- You could try to temporarily unban all banned IPs. Maybe for some unknown reason Fail2Ban banned Let's Encrypt servers?
- You could check with DNSViz | A DNS visualization tool and intoDNS: checks DNS and mail servers health whether DNSSEC records exist for the domain and whether such are fully valid. Else some requests might go through, others might not.

 

[Nextgen-Networks]

Hello @Peter Debik,
I've unbanned all IPs and also temporarily deactivated Firewall as well as Web Application Firewall.
DNSSEC-Records for that affected domain have not been configured in the past - therefore should not affect the renew process.
DNS-Records itself looking good and do not show any Errors.

 

[Peter Debik]

Have you verified that the domain is routed to the correct server?

 

[AYamshanov]

From my side, I would suggest to perform a test with Let's Debug, probably makes sense to check IPv6 address(es) (not only IPv4), is everything correct with them? with firewall rules? etc.

 

[Peter Debik]

Let's Debug

Interesting tool, good to know.

 

[Nextgen-Networks]

Have you verified that the domain is routed to the correct server?

Yes - please see last screenshot of initial post
Not only the domain is connected correctly - also the acme-challenge file could be read from external.

 

[Nextgen-Networks]

From my side, I would suggest to perform a test with Let's Debug, probably makes sense to check IPv6 address(es) (not only IPv4), is everything correct with them? with firewall rules? etc.

This helped a lot to figure out the detailed root cause.

 

[netbuild]

Hi,

the problem arises when the forwarding from http to https has been activated in the hosting. Deactivate the "SEO-related redirection" and test it again.

Regards
Patrick

 

[Peter Debik]

the problem arises when the forwarding from http to https has been activated in the hosting. Deactivate the "SEO-related redirection" and test it again.

Very unlikely.

 

[t.echternach-weber]

It may be "very unlikely" even that is not really a Professional answer.
If its unlikely, then plz explain why it works????
Automatic fails then i remove the "SEO redirect to HTTPS" do it again and it works...yeah very unlilkely.

 

[netbuild]

Hello,

we have this problem every day and even manually creating the certificate only works when the SEO-based redirect has been disabled.

If you don't believe it, then try it out. We now have over 200 of these tickets.

Regards
Patrick

 

[Peter Debik]

It may be "very unlikely" even that is not really a Professional answer.
If its unlikely, then plz explain why it works????
Automatic fails then i remove the "SEO redirect to HTTPS" do it again and it works...yeah very unlilkely.

In all current Plesk versions, the SSL token file is not stored inside the document root directory. It used to be in old, outdated versions, and it could be if you have deliberately configured it to be, but in general it is not. The case described above does not indicate any issue with the storage path of the token. Instead, it explains that the reason for the failure was a missing A or AAAA record for the domain.

As in typical setups, the token is not stored in the document root, it does not matter whether that is addressed by http or https, because even on an existing redirect to https that part will be bypassed by the web server configuration. The token can still be delivered from the common directory. This is the same case for forwarded domains. If your assessment was true, it would mean that forwarded domains could also not have SSL unless the forward was turned off, because in such a case the token could not be accessed. Actually, it was the case in old Plesk versions, but it no longer is.

You can check whether your configuration uses a common challenge directory with plesk ext sslit --common-challenge-dir -info.

 

[t.echternach-weber]

i checked every server we run, and get always the result above, however, the automatic renewal still fails.

 

[Peter Debik]

What result do you get when you check it with Let's Debug ?

 

[t.echternach-weber]

Lets Debug shows "OK".

 

[netbuild]

So the answer is a bit of a cheek. Do you think I get up in the morning and think up a scenario like that?

It is definitely due to the SEO-related redirection and not to the DNS records, which are even created by Plesk itself and can also be queried via NSLOOKUP or DIG.

You can trigger the RENEW until Let's Encrypt blocks the server due to too many attempts. As soon as you deactivate the SEO-related redirection, the RENEW goes through immediately.

 

[Peter Debik]

So the answer is a bit of a cheek. Do you think I get up in the morning and think up a scenario like that?

Nobody has claimed that. It doesn't help to make accusations here.

You can trigger the RENEW until Let's Encrypt blocks the server due to too many attempts.

Why would anyone want to do that?

As soon as you deactivate the SEO-related redirection, the RENEW goes through immediately.

You already mentioned that.

You could check whether the route for http traffic is the same as for https traffic.
Are you using a proxy like Cloudflare? Could the issue be linked to port-related setting there?
Do you have any individual Nginx or Apache configuration directives in effect in your domain ("Apache and Nginx Settings")? These could take precedence over the default 301 in the "server" bracket of nginx.conf of the domain.

Please verify what the location setting in the "#extension letsencrypt" section in your web server configuration files is before and after SSL redirect changes. It should look like the following quote in /var/www/vhosts/system/<your domain>/conf/nginx.conf

        #extension letsencrypt begin
        location ^~ /.well-known/acme-challenge/ {
                root /var/www/vhosts/default/htdocs;

                types { }
                default_type text/plain;

                satisfy any;
                auth_basic off;
                allow all;

                location ~ ^/\.well-known/acme-challenge.*/\. {
                        deny all;
                }
        }
        #extension letsencrypt end

 

[t.echternach-weber]

Hello,
there are no redirects configured in nginx.conf and the Lets Encrypt snippet is exactly the same as yours.
I can't post it here bc i would have to blackout so much stuff,.,,,GDPR
I can tell you it is a shared hosting system with a lot of Domains on it, and i am searching for this Error since months now.
We are not unexpirienced here and did also a lot of research, but i couldnt find anyone who could post a successful automatic lets encrypt renewal.