Upgrade to Ispconfig 3.3.0p2 and let's encrypt problem

Good morning,

We are updating ISPConfig from version 3.2.11p2 to version 3.3.0p2 on our stack (1 master and several slaves).
We are noticing abnormal behaviour on Let's Encrypt (with Certbot). If a domain is configured on the server but for some reason no longer points to the machine (perhaps the customer has decided to point the web elsewhere, or the domain has expired but has not yet been removed from the server), a procedure (I think from ISPConfig, but I am still investigating) occasionally starts that fails to check the certificate on Apache for that domain, with this error:

```
Sep 29 13:08:28 NODE.MYSERVER.COM apachectl[1436377]: SSLCertificateFile: file “/var/www/clients/clientXXX/webXXXX/ssl/MYDOMAIN.COM-le.crt” does not exist or is empty
Sep 29 13:08:28 NODE.MYSERVER.COM apachectl[1436373]: Action “start” failed.
29 Sep 13:08:28 NODE.MYSERVER.COM apachectl[1436373]: The Apache error log may have more information.
29 Sep 13:08:28 NODE.MYSERVER.COM systemd[1]: apache2.service: Child 1436373 belongs to apache2.service.
29 Sep 13:08:28 NODE.MYSERVER.COM systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
```

Killing Apache and not allowing it to restart until the web host has been deactivated from the control panel.
Has anything changed in this regard in the latest version of ISPConfig?
Because until last week, we didn't have any similar problems with the previous version.

Thank you very much.

 

I believe nothing has changed.
If the domain no longer points to your server, Let's Encrypt will fail trying to get the certificate. You must remove the disappeared domain from getting certificates. If you run certbot, it has command line tool to remove certificate.
I'm not sure but the Read before posting may explain this somewhat.

 

Nope, i'm debugging right now. Comparing the previous let's encrypt module with the new one. A lot is changed. From what i'm seeing all the part of removing the certificate is new.

 

Still checking but Probably is this one the cron that cleanup the unused cert `lib/classes/cron.d/800-letsencrypt_cleanup.inc.php` but if that the case, if the website is still enabled removing that cert, broke apache.

 

yes i have found exacly in this moment:

Code:

$web_config = $app->getconf->get_server_config($conf['server_id'], 'web');
                $le_auto_cleanup = empty($web_config['le_auto_cleanup']) ? 'n' : $web_config['le_auto_cleanup'];
                if($le_auto_cleanup == 'n') {
                        parent::onRunJob();
                        return;
                }

but due that is a large network, generally we update before all the slave servers, and then for last the master. Generally the procedure involve several days to complete.
By the way: when we will update the master, is enough put le_auto_cleanup = n, or we need to resync everything?
ty

 

Yes thank you for the feedback. But is not always possible upgrade everything in the same day.
By the way, now i have managed to update all the remaining server, then disabled on all the revoke/remove of the certificate. And i hope this solve the issue for the future.
The only problem is if we have some ssl cert removed in the meantime, but tomorrow i will find how to search them.

From what I can see, if for any reason the webdomain is active but it point out (so not on the server, and this can happen if for exaple the customer decide to point out the website from his zone, without telling us this) that the let's encrypt can't obvioulsy verify the domain, the procedure will remove the ssl certificate from the let's encrypt, but not the symlink from the apache config of the vhost. And this kill apache.