Changing to ZeroSSL free certificates

Hello,
I'm in the process to leave LE and adopt ZeroSSL because I was experiencing repeated problems with the LE renewals.
To solve these unexpected problems I was wasting a lot of time, attempting ISPC upgrades, checking the certificates, possible blocks by the firewall, dns and apache requests.... In short, I have LE renewal failures, and when I try to fix the issue it's quite a hell.
When I monitor the renewal process after activating this inside ISPC panel, there is a long log, in where in some moment I receive one error like this:

Code:

# tail -f /var/log/ispconfig/acme.log

[Tue 10 Feb 2026 14:25:20 PM CET] original='{
  "identifier": {
    "type": "dns",
    "value": "domain.com"
  },
  "status": "invalid",
  "expires": "2026-02-17T11:19:01Z",
  "challenges": [
    {
      "type": "http-01",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall/800402102/......2/A1smsww",
      "status": "invalid",
      "validated": "2026-02-10T11:21:11Z",
      "error": {
        "type": "urn:ietf:params:acme:error:connection",
        "detail": "During secondary validation: 24.24.24.24: Fetching http://domain.com/.well-known/acme-challenge/ae4.....FRae: Timeout during connect (likely firewall problem)",
        "status": 400
      },
      "token": "ae43eR.....TRY",
      "validationRecord": [
        {
          "url": "http://domain.com/.well-known/acme-challenge/eo49eY7al_ZpvLh9eVx45feYsvmMnW7_yFiNGt0LBDc",
          "hostname": "domain.com",
          "port": "80",
          "addressesResolved": [
            "24.24.24.24"
          ],
          "addressUsed": "24.24.24.24"
        }
      ]
    }
  ]
}'

after a long log of success then appears that type of failure about "Timeout during connect (likely firewall problem)"

However, I'm not able to find any blocking in my firewall. And the LE darkness about their multiple unknown sources it makes really difficult to locate the error. Finally I'm tied of these LE problems and I'm starting to migrate the free certificates to ZeroSSL.

I have installed the first ZeroSSL certificates and seems to work pretty well, and the renewal process seems to be cleaner at least in my view.
I had knowledge about ZeroSSL, although I didn't know that they allow the creation of accounts and multiple certificates from the command line. Now they have an AI help quite useful to get info: https://help.zerossl.com/hc/en-us

However, I'm not sure how the adoption of ZeroSSL can affect to ISPC. I'm using the same acme.sh script existing inside ISPC, without apparent problems. Although I'm forced to create one script to rename the certificates inside the Apache config websites because the ZeroSSL certificates names doesn't contain the "*-le".

Inside ISPC panel, I have disabled the LE option in the related websites, and keeping only the SSL option enabled. My question is to know if maybe there are more things to do in order to avoid possible problems with ISPC.

I have found this thread in the forum but no more added info:
https://forum.howtoforge.com/threads/zerossll-intergration-to-ispconfig.87275/

Any help or advice for this change would be appreciated

thanks!

 

You should troubleshoot the port 80 reachability instead of assuming an ISPConfig issue. Let’s Encrypt works reliably for many installations, and when problems occur, they are usually due to network conditions rather than the control panel itself.

Looking at your log, the key phrase is “During secondary validation.” This means Let’s Encrypt performs multi-point validation. If one validation location succeeds but another cannot connect, the authorization fails. Because of this, you need to verify that port 80 is reachable globally, not just from your own location.

A useful external test tool is: https://check-host.net/check-http?host=domain.com so if some locations report timeouts while others succeed, that confirms a partial network reachability issue.

If the problem persists, please also provide your hosting environment (home server, VPS, or which provider) and output of "iptables -L -n -v" as that information helps determine where traffic might be filtered.

You should also be aware that when only some Let’s Encrypt validation nodes fail while others succeed, the cause is often selective network filtering, not a full port 80 outage. Common real-world causes include:

1. Geo/IP filtering (common on VPS firewalls)
Some providers or firewall templates block traffic from certain regions (for example parts of the US, Eastern Europe, or Asia-Pacific).
If a Let’s Encrypt validator comes from a blocked IP range, the connection times out, while another CA validating from a different region (like ZeroSSL) may succeed.

2. Provider DDoS protection or SYN flood filters
Some hosting providers use automatic mitigation systems that silently drop connections that look like scanning or rapid automated validation. Let’s Encrypt’s distributed validators can trigger these protections more often than other CAs.

3. Fail2ban or CSF temporary bans
If previous validation attempts were flagged as suspicious, a Let’s Encrypt validator IP might be temporarily blocked. You can check with "fail2ban-client status" or, if CSF is installed "csf -g <validator IP>".

4. Asymmetric routing
In some networks, requests reach the server but replies leave through a different upstream route that is filtered or dropped, resulting in connection timeouts even though the service itself is running.

Since Let’s Encrypt requires all validation points to succeed, any of the above conditions can cause issuance to fail while another CA, such as ZeroSSL, may still succeed.

 

thanks ahrasis for the reply, and sorry the delay

My question was more centered to know the possible things to do in case that we use ZeroSSL.

Although what you writes is right. The problem arise when some day the renewal fails, and then it is a nightmare knowing the cause because LE don't provide useful info. They don't provide useful diagnostics to know the ip source of the failures.

I have those security measures you writes and more, like block lists, temporary banning of countries, reputation ASN and etcetera. Some failures can be easily located while others no. It depends of the logs. LE uses both http and dns requests from multiple sources , and some failures are not easily traced. This is not impossible although sometimes it request a lot of time. And I don't agree with shutting down the firewall for the renewals just because LE have this darkness design in where they don't provide necessary information to solve these problems.

It seems they use cheap cloud networks for their requests, and probably some ip's falls into ASN or cdir block lists because a poor reputation or a malicious activity from these networks. It means their requests can be blocked at the iptables kernel level, and it forces to start a renewal process, monitoring and filter the requests, locating the possible blocked ip, whitelisting that ip and hoping the same will be again in the new process, taking care about the consecutive attempts because it can paralyze the renewal... All together this is not a right thing for a service providing certificates to billion people.

That LE design is supported in obscurity, apparently to protect themselves when they serve the certificates, although then the problems goes for the users.
In fact I don't understand what happens with the SSL free certificates. Why all that complicated design with repetitive 3-monthly renewals. The free SSL certificates lacks of any money insurance. Why no serving the free SSL certificates to the domain register level , to be renewed yearly together with the domain name. And that's all.

Anyway, my question was not really centered in that strange design neither in its failures. The certificate renewal is a critical thing because it leaves a website out of service. And I don't have wishes to waste more time solving the LE problems after finding a website out of service because LE

Really I was asking to know the things to do if we use ZeroSSL with ISPC.

- I have checked the SSL option and leaving unchecked the LE option. Is this enough? Should we alter the acme script in some way?

- The LE certificates are named "-le" and I'm forced to change manually the ZeroSSL certificates names into the Apache config.
Is there some way to avoid this?. Should I write an script to rewrite the Apache config lines with the certificate names after a SSL cert. renewal?. I mean, is this necessary to avoid rewrites in ISPC updates?

- Are there more things to be aware of?

these questions are my doubts. Maybe these can be useful for others.

thanks!