I guess certbot is the software that we had to implement the most workarounds for failures and inconsistencies yet, that's why we started to implement acme.sh in ispconfig master branch and will start using it with ISPconfig 3.2
May you please let me know which operating system and version and which python version you use and which method you used to install certbot 0.31? Maybe the difference in certbot behavior is caused by a different python environment.
I originally used the certbot/letsencrypt provided by Ubuntu, but that's only apparently only 0.23 - and whatever ISPConfig was doing was throwing errors. So, then I pulled it straight from the source, and put it in opt, then redirected the certbot binary links to the /opt/certbot one. That allowed ISPC to run. Then the original post.
Did you purge the old version of certbot before installing the new? So you do not have two versions of certbot on your host.
I agree with @Taleman. Ensure that you properly removed the default certbot for your server. I'd however prefer to use the certbot ppa for easy update but it is of course just a matter of choice: Code: sudo add-apt-repository ppa:certbot/certbot sudo apt-get update As a note, I think most of the reported problems with Let's Encrypt started when support to its acme v02 API was added; which is basically a transitional problem, rather than certbot as its official client. Another remote cause I think was python version used by certbot, so I always have both versions, 2 and 3 installed, just in case.
If you have the same issue, have you tried the same debugging and fixing procedures in this thread? Could you say exactly what issue it is you have? Just saying it is the same has often fooled me in this forum.
Yes, the issue still exists. Please, don't blame certbot itself. If I manually run certbot, it works fine. The issue is with the ISPConfig integration with Certbot, not with purging old versions. (the old version was removed, and then I manually removed anything left behind) For example, I just created a brand new domain, told it to create a certbot cert, and ... it failed. 17.04.2019-20:57 - DEBUG - Create Let's Encrypt SSL Cert for: 3fabinc.com 17.04.2019-20:57 - DEBUG - Let's Encrypt SSL Cert domains: --domains 3fabinc.com --domains www.3fabinc.com 17.04.2019-20:57 - DEBUG - exec: /usr/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v02.api.letsencrypt.org/directory --rsa-key-size 4096 --email [email protected] --domains 3fabinc.com --domains www.3fabinc.com --webroot-path /usr/local/ispconfig/interface/acme 17.04.2019-20:57 - WARNING - Let's Encrypt SSL Cert for: 3fabinc.com could not be issued. 17.04.2019-20:57 - WARNING - /usr/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v02.api.letsencrypt.org/directory --rsa-key-size 4096 --email [email protected] --domains 3fabinc.com --domains www.3fabinc.com --webroot-path /usr/local/ispconfig/interface/acme 17.04.2019-20:57 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/3fabinc.com.vhost In this case, it doesn't even create the letsencrypt files that were created before. Again, I suspect that it's because this server is close to a decade old, has been upgraded through three hard drives and at least four major revision upgrades on the machine, let alone ISPConfig.
I would like to add that I experienced this issue as well recently. I purged the certbot packages and all conf files, then reinstalled. It worked for a day and is now having the same issue with nothing after the [[webroot_map]] section. Latest stable version of ISPConfig 3 installed on Ubuntu 18.04.2 LTS with latest certbot installed.
Hi everyone, We started experiencing this recently too. To give you all some context we manage 20-ish servers through ISPConfig and never had a lot of issues with it. We first encountered this kind of issue a few weeks ago on a brand new server (debian 9 + ispconfig 3.1, don't remember certbot version but it's supposed to be quite recent since the server is only a few weeks old). The server is hosting 3 websites, only one of them need manual "webroot_map" update. We made a lot of tests, revoked & deleted the certs multiple times but nothing worked, we gave up and went for manual .conf update. This morning I had the problem with an older server (debian 8 + ispconfig 3.1 + certbot 0.32) which is hosting 60-ish websites, never had this kind of issue before. The only common thing I can think of between these 2 issues is : when we first asked for the cert, one of the website alias wasn't pointing on our server and the generation failed. I did not make any further tests and honestly don't know how this could affect the .conf generation since we deleted the bad aliases right after making further SSL generation requests, revoked and deleted the certificates later on etc.
Of course, you have to blame certbot as it has a bug in recent versions which cause the domains to be missing in the renewal config file and this causes ispconfig to fail to find the right cert. So the sole problem is certbot here as it sometimes (not always and not on all servers) fails to write its own renewal config files in the right way, it simply misses to mention which domains are inside the ssl cert sometimes. As we can't wait for certbot to fix their bug, we implemented a workaround in ISPConfig a few days ago to search for a matching SSL cert in case the certbot renewal config is broken for a given SSL cert. All you have to do is to update your ispconfig system to 'git-stable' by using the ispconfig_update.sh command, then tick the ssl and letsencrypt checkbox again in the website.
Agreed that the real fix should be done at certbot side (especially certbot version 0.31 or above since it causes the current problems) and thank you very much to all developers for the new "work around" in letsencrypt.inc.php. I have been using dns-01 challenge and with custom vhost (since I only have four tld domains run from my server) but reading the new codes in letsencrypt.inc.php, I think they will is also be useful to check for certificates not issued by ISPConfig. I am going to try looking deeper at this since there were requests to support creating LE SSL certs for websites other than using webroot approach especially via dns-01 challenge like what I am using now. I would also suggest that since the 3.2 will also be using acme.sh other than certbot, the added acme.sh code in ISPConfig should also attempt the same thing as well, whether via ISPconfig DNS server or others.
We might add some code for acme.sh as well to search for LE certs, but as acme.sh is quite stable in regard to SSL cert names, so such code to seek for any matching cert should not be necessary.
Sorry, but I just tested git stable via ispconfig_update.sh but somehow the new code changed all my latest privkey.pem in LE archive folder resulting nginx restart failure due to changed key. Strange as I am not sure what my fault is. I gonna restore the backup and return back to 3.1.13 for now. I mean support for dns servers i.e. using dns-01 challenge. It is not yet implemented so far.
Hi, we are serving many websites over HTTPS and ran into this issue last week with exactly _one_ domain. Using Ubuntu Xenial, ispconfig-3.1.13, certbot-0.31.0-1 Using this letsencrypt.inc.php seems to solve it for us. Certificate was created by setting checkbox "Let's Encrypt" in ISPC Webinterface; cert was created, but SSL config not activated. On next try, the certificate was already there ("... not due to renewal"), but also no config created. Even DEBUG log did not tell any reasons. Thanks a lot, Marianne
I doubt that these changes are related to ispconfig, take a look at the ispconfig code, ispconfig does not contain any code to write or modify these files. Yes, that's what the fix is made for that I mentioned above (#32). The new code contains an alternative search routine for the certs in case that the certbot bug kicks in.
Yup. I did re-check the code and it should not affect my LE since my server is using certbot ppa version 0.29 and the new code is checking for 0.30 and above. The fact that privkey.pem file for my server was changed in about the same time with the update may be caused by other things as there are also some other tests being made in this server. This is for me to investigate. Plus, I re-update back to git-stable again after restoring and this time it all went fine.
I'm not going to expect this to change anything, due to my _very_ old configuration, but I thought I'd add in that after all of this, my domains won't renew. Attempting to renew cert (mail.bkwm.com-0001) from /etc/letsencrypt/renewal/mail.bkwm.com-0001.conf produced an unexpected error: Missing command line flag or config entry for this setting This happens for all of the letsencrypt sites, and that is with the latest git-stable. I'm just going to try to replace the server within the next 10 days, before they finish expiring.
Just to toss this out - the name of my mail server goes to RoundCube. Is ISPConfig capable of having the .well-known end up there? (I don't know why this would be a problem, as before, they were being created just fine)
