Letsencrypt site files still exist after domain removal.

I found that LE was still trying to renew a cert for a domain that has been deleted from the system.

Upon investigation i found that in /etc/letsencrypt/ all of the files/confs were still there and thats why LE was apparently attempting to renew the cert.

Is this normal or has something gone wrong with my installation.

ISPC 3.1

 

Okay cool, i've removed them now but a clean up option is welcome.

 

Also, when a site is deactivated, letsencrypt is kept active. Has the disadvantage, that it still tries to renew which fails without an active web. Furthermore, when reactivating the site after the certificate is expired you get a lot more errors that users don't understand.
For example, I have a user which hosts a birthday invitation site each year. It is deactivated for ~10 months and reactivated for 8 weeks. Now that I know it, he calls me and I renew his cert manually. So, a button to initiate a cert renew from ispc would be nice. At least the renew should be paused when deactivating/deleting a site and when reactivating, a renew should be initiated.

If the web is down, renew will fail. If it is used in other software, then it should be manually configured (with dns challenge or whatever).

Great to hear! Actually, I was thinking to create a ISPC-Git account to make such a request but have to admit that I was too lazy (shame on me!) :/

 

You can clean easy by:

Code:

certbot delete --cert-name deleteddomain.test

Or similar.

 

Certbot and other LE client cannot renew a domain certs after their expiry, thus, reactivating a site will never renew its expired certs but should supposedly create new certs for its domain when LE SSL button is selected / ticked.

I do not see this (deleting LE certs after a website is deleted) as having high urgency though it could be a nice option to have because as mentioned above, some LE certs created may still be in use for other services other than for the website.

An option button to delete the certs (with a default unselected) is therefore the best in my opinion rather than automatically deleting a domain certs upon its website's deletion.

 

I can, but the users can't.

A user can't use that cert for anything else. Furthermore, the cert cannot be updated when the web is missing (in the standard ISPC configuration we are talking about). I don't see, how that scenario has any real world implications. If it is used somewhere else, it would be better to fail right at the time the admin kills the web than 2 months later when the certificate exires.

The case that a certificate is used for other services while the web is being deleted is so unusual, that the default should be to delete the cert (maybe with a note saying: "Make sure this certificate is not used anywhere else").
As you pointed out: An expired cert needs to be recreated, so the user has to deactivate letsencrypt, call the admin to delete the expired cert and reactivate letsencrypt.

 

This not true and not what I have said. There is no need to do so for the expired certs, but the existing certs can still be used by the reactivated website if it is still within 90 days and will be renewed at night as usual.

 

There will be a try to renew them. But with the web being deactivated or deleted, the renew will fail. (unless configured for DNS challenge which has to be done manually anyway)

You said:

So, how should a client get LE working again when he reactivates a website after a year (i.e. after the cert is expired)?

 

This is what I have said with clear meaning of it. The reactivated website should obtain a new certs if the previous one had expired, not by renewing it.

Edited: Let me further explain based on my comprehension:

1. Renewal use "certbot renew" command, thus this will never work for expired certs but the LE SSL box being ticked will first check for the site's available certs and if they are still valid, they will be used but if they had expired, new ones will be applied using a different command that is "certbot certonly".

2. The ISPConfig LE renewal script runs every night, whether or not some certs had expired, thus will always attempt to renew the valid ones that are after 60 days and before 90 days, either the certs have an active site (if using webroot) or not but have proper dns setup (if using dns validation).

Therefore, to me, there is basically no need to delete any LE SSL certs already obtained in any ISPConfig server but I do agree an option for it is definitely would be nice.

Regarding what should be the default, that is always argueable, with my preference is unselected but that is up to ISPConfig developers to decide.

 

Correct, that is what it should be. However, did not happen for me.

Thats neat. However, has not worked for me (I am now on acme.sh anyway). I also have not found that logic in the code. Could you lead me? In my understanding, the cronjob just does a renew: https://git.ispconfig.org/ispconfig...er/lib/classes/cron.d/900-letsencrypt.inc.php
Or does a certbot renew on an expired cert automatically get a new one?

Anyway, when reactivating a site a LE renew should be issued (or a certonly). At the moment the client is left with an expired cert and a lot of scaring warnings. Even though over night, the cert might be reissued and the problems miraculously gone.
But in my experience, the clients wants to have a working site, right after activating it and not on the next day. That leaves me in deactivating letsencrypt, deleting the cert and reactivating it to get a new and valid cert right away. (now with acme.sh I can do this easily from the command line without having to fear this will break any ispc setup)

 

There is "renew" in line 74 of that script and it will run "certbot renew" command if you are using certbot and that command will never renew any expired certs.

No. Reactivating a site will not do anything to any of the certs. You will need to check the LE SSL box for it to check its domain renewal conf. It should always, when selected, update the current certs or create new certs if there is none exists or the current ones are already expired, because of the "certbot certonly" command.

And again no. No certs will be renewed and issued at night unless that certs are still valid but have passed 60 days.

I can't comment on your experiences and ways of doing it but to me the current code should work as what I have explained.

You may want to refer to certbot manual to understand how it works other than ISPConfig codes: https://certbot.eff.org/docs/using.html

 

Glad we can agree on this one. However, I could not find anything about that in the docs (GoDaddy certificates can't be renewed 30 days after expiry, but for letsencrypt I could not find such a thing. So it should be possible to get a valid cert with "certbot renew" even with an expired cert. (can't try it now, though)

Correct. And I was suggesting that it should in the future. If you deactivate a site for more than 90 days, the certificate expires and the user/client has no option to get a valid cert again without admin interaction (or waiting for the nightly renew). If I am wrong, I would appreciate a "how to" how this should work.

 

No, it is not possible at all: https://certbot.eff.org/docs/using.html#renewing-certificates

@Jesse Norell, some of them did go through 2 years back, some just did recently but to note the most important one that check and fix renewal conf creation (due to certbot updates / errors on webroot webpath code), actually came from another member then was improved by the developers and I think started available somewhere in June 2019 via git-stable i.e. long after version 3.1.13 but before version 3.1.14 was released.

I think that is the point when the developers started to develop an integration with another popular letsencrypt client (acme.sh) which is now already an official part of ISPConfig.

The acme.sh is now the main script that will be used in ISPConfig, if no certbot is detected.

 

Looking at the /root/acme.sh/ dir I still see a number of domains for sites that have been deleted, and the cron script faithfully sends root an email listing all the failures.

Either auto-removing the domain from acme.sh when the site is deleted, or some form of admin interface to manually remove stale acme entries would really make a huge difference here

 

I do not think that the requested feature has been implemented yet but I have not visited the git on this issue.