Hi, I have just now created a Let's Encrypt certificate for example.com including the auto subdomain www.example.com - works fine. I have also created a separate vhost for english.example.com but I'm unable to create a certificate for this domain. I have made sure there is no auto www. subdomain for that. "example.com" is not the real domain of course - I have just anonymized the domain name. Output from /var/log/ispconfig/ispconfig.log Code: 27.04.2022-16:03 - WARNING - Could not verify domain english.example.com, so excluding it from letsencrypt request. 27.04.2022-16:03 - WARNING - Let's Encrypt SSL Cert for: english.example.com could not be issued. english.example.com IS accessible, both from the outside world as well as on the server itself. `ping english.example.com` on the server returns the server's public IP `nslookup english.example.com` on the server returns the server's public IP `wget english.example.com` on the server downloads the website's index.html file as expected (content verified) There is an A record in the DNS system for english.example.com specifically, in case that matters. Normally I just create *.domain.com for subdomains. english.example.com is accessible from the outside world via the browser and displays the website just fine. I'm aware that I can disable Let's Encrypt pre-checks, but I can't risk getting banned due to invalid requests so I'd rather solve this properly. I need the following domains and subdomains to have HTTPS enabled: example.com and www.example.com english.example.com (separate vhost) german.example.com (separate vhost) I'm stuck here. Any advise would be appreciated - thanks
Thanks @Th0m - I have already gone through that - please see my comments: Check that you have a Let’s Encrypt client installed. On servers installed before the release of ISPConfig 3.2, this is most likely certbot. On servers installed after the release, it's most likely acme.sh. My server dates back to Debian 7 or 8 so it is based on Certbot Check that the Let's encrypt client 'certbot' is updated (when using certbot). The latest version I can get is 1.6.0. `certbot-auto --version` returns: Code: certbot-auto and its Certbot installation will no longer receive updates. You will not receive any bug fixes including those fixing server compatibility or security problems. Please visit https://certbot.eff.org/ to check for other alternatives. certbot 1.6.0 - Is this really the problem? I kind of doubt it. Is there any official ISPConfig guidance to fix this? Check that you run the latest ISPConfig version. I do - ISPConfig 3.2.8p1 When your server is behind a NAT router so that the server itself can not reach the hosted domains, then enable the option "Skip Letsencrypt check" under System -> Server config -> server1.example.com -> Web. The website is accessible as described in my initial writing. If you are using Cloudflare proxy, then you can not get a Let's Encrypt SSL cert. Using Cloudflare DNS (without proxy function enabled) is fine though. I'm not using Cloudflare. Check that all domain names (incl. auto subdomain www etc), subdomains and aliasdomains really point to the right website in DNS and are working. Open one after another in your browser and test that. They work - verified both remotely and on the server itself. If you still use Apache 2.2, then update your ispconfig to the latest version with the ispconfig_update.sh script to get an updated vhost template. After you did that, use Tools > resync to apply the new template to all sites or apply it to a single site by altering a value in the site settings and press save, before you try to activate Let’s Encrypt again. This is only necessary on apache 2.2 systems, newer apache 2.4 or nginx systems are not affected. The server is running Apache/2.4.38 (Debian). If you updated from ISPConfig < 3.1 to ISPConfig > 3.1 and deselected the "Reconfigure services" option during update (which is selected by default), then Let’s Encrypt will fail as your server is missing the Let’s Encrypt configuration in the ispconfig apache configuration files. Redo the update and chose to reconfigure services in that case. I always allow reconfiguration. In fact I updated ISPConfig today and allowed reconfiguration of services. Check that 'Server Migration Mode' option under System > Server Config is not enabled, as migration mode disables the creation of new Let's encrypt certificates. I just checked - it is NOT enabled. Interesting, I have had problems getting Let's Encrypt to work for vhosts for some time now. Creating a website and immediately enabling Let's Encrypt usually doesn't work. I found that creating the Vhost, then configuring redirection from www.domain.com => domain.com, and then enable Let's Encrypt (3 separate steps where I save the changes every time) solved the problem. I always have to make a change to the website before I can enable Let's Encrypt - not sure why. But Let's Encrypt haven't exactly been working buttery smooth for some time now. Perhaps there is a bug in play. But it may not even be related to my current problem.
At the end of that FAQ it tells you that if this doesn't help, to use debug mode and share the output. So do that.
@Th0m I shared the output from ispconfig.log (in debug mode) in my initial question - but I probably left out something I deemed irrelevant. Here is the complete output Code: 27.04.2022-19:07 - DEBUG [plugins.inc:155] - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 27.04.2022-19:07 - DEBUG [server:177] - Found 1 changes, starting update process. 27.04.2022-19:07 - DEBUG [plugins.inc:118] - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_update'. 27.04.2022-19:07 - DEBUG [plugins.inc:118] - Calling function 'update' from plugin 'apache2_plugin' raised by event 'web_domain_update'. 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: chattr -i '/var/www/clients/client72/web184' - return code: 0 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: chattr +i '/var/www/clients/client72/web184' - return code: 0 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: df -T '/var/www/clients/client72/web184'|awk 'END{print $2,$NF}' - return code: 0 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: which 'setquota' 2> /dev/null - return code: 0 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: setquota -u 'web184' '0' '0' 0 0 -a &> /dev/null - return code: 0 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: setquota -T -u 'web184' 604800 604800 -a &> /dev/null - return code: 0 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: chattr +i '/var/www/clients/client72/web184' - return code: 0 27.04.2022-19:07 - WARNING - Could not verify domain english.example.com, so excluding it from letsencrypt request. 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: which 'apache2ctl' 2> /dev/null - return code: 0 27.04.2022-19:07 - WARNING - Let's Encrypt SSL Cert for: english.example.com could not be issued. 27.04.2022-19:07 - WARNING - 27.04.2022-19:07 - DEBUG [db mysql.inc:521] - NON-String given in escape function! (boolean) 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: which 'apache2ctl' 2> /dev/null - return code: 0 27.04.2022-19:07 - DEBUG [apache2 plugin.inc:1875] - Writing the vhost file: /etc/apache2/sites-available/english.example.com.vhost 27.04.2022-19:07 - DEBUG [apache2 plugin.inc:1993] - Apache status is: running 27.04.2022-19:07 - DEBUG [services.inc:56] - Calling function 'restartHttpd' from module 'web_module'. 27.04.2022-19:07 - DEBUG [system.inc:2082] - Trying to use Systemd to restart service 27.04.2022-19:07 - DEBUG [system.inc:2399] - safe_exec cmd: systemctl is-enabled 'apache2' 2>&1 - return code: 0 27.04.2022-19:07 - DEBUG [web module.inc:246] - Restarting httpd: systemctl restart apache2.service 27.04.2022-19:07 - DEBUG [apache2 plugin.inc:1996] - Apache restart return value is: 0 27.04.2022-19:07 - DEBUG [apache2 plugin.inc:2007] - Apache online status after restart is: running 27.04.2022-19:07 - DEBUG [modules.inc:240] - Processed datalog_id 3556 27.04.2022-19:07 - DEBUG [server:217] - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
ISPConfig tested if the domain is reachable by doing the same test that LE would use (access a token by http://..., but from the local server and not a remote location) and this failed. So either there is an issue reaching this subdomain from the server itself, or you added some custom rewrite rules that block access to the LE tokens.
Try Code: echo "Hello World" > /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/test.txt then request http://english.example.com/.well-known/acme-challenge/test.txt from the server itself, this is more or less the test which is failing. It is accessible on all ip addrs via http (port 80), and not just https (port 443)?
Oh! This is not just a domain lookup but it actually needs to aquire data via HTTP - got it! Rewriting was in fact in play. Disabling it solved the problem. Thank you so much. This was driving me crazy. Thanks @Th0m, @till and @Jesse Norell - appreciate you Suggestion: Add "Make sure to disable any URL rewriting and redirection" in the debug post (https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/)
If you are using custom rewrite rules, then take care that your rules exclude the (virtual) subdirectory .well-known/acme-challenge/ from rewriting.
@till Did you mean add that last comment to https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/ ? Or was it a reference to something else? I don't see rewrite rules mentioned on https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/)
This was just meant as a general hint, if you create your own rewrite rules, then you should take care to exclude this path from your rules.
