Hi, I made fresh installation of ISPConfig (https://www.howtoforge.com/tutorial...8-4-jessie-apache-bind-dovecot-ispconfig-3-1/). Unfortunatelly I'm not able to make Lets encrypt working properly. Domain works perfectly but when I check use SSL and Lets Encrypt in ISPConfig, the certbot succesfully recieve new certificates, saves them to /etc/letsencrypt/.. but it doesn't create symlinks from /var/www/<domain>/ssl to /etc/letsencrypt/live/<domain>/.. ISPConfig: installed with 3.1.4, now 3.1.5 Certbot: 0.15 Any advice would be appreciated. I also have access to second installation of ISPconfig 3.1.3 with certbot 0.9 running perfectly.
LE can fail when you activate it right at site creation. Try to activate it again now. In case you create a new site with LE, better create the site and click save, then enter it again and activate LE.
I've already tried it. And now again without success. Certificates saved in /etc/letsencrypt/.. but no symlinks. Also tried on subdomain. Same situation (anonymize domain in log) DEBUG:certbot.storage:Writing new config /etc/letsencrypt/renewal/test.test.cz.conf. So when I type https:// domain . tld it offers me my server signed certificate.
Interesting news.. After setting Log level to Debug, lets encrypt stars working. After setting back to errors, unchecking LE in websites and manually deleting symlinks, lets encrypt fails to create them again (after turning on LE in websites). I have no idea why it works only with Log llevel to Debug. domain. tld is anonymized real domain. Here is log: 30.06.2017-23:47 - DEBUG - Calling function 'check_phpini_changes' from plugin ' webserver_plugin' raised by action 'server_plugins_loaded'. 30.06.2017-23:47 - DEBUG - Found 1 changes, starting update process. 30.06.2017-23:47 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' r aised by event 'web_domain_update'. 30.06.2017-23:47 - DEBUG - Calling function 'update' from plugin 'apache2_plugin ' raised by event 'web_domain_update'. 30.06.2017-23:47 - DEBUG - Verified domain domain. tld should be reachable for letse ncrypt. 30.06.2017-23:47 - DEBUG - Verified domain www. domain. tld should be reachable for l etsencrypt. 30.06.2017-23:47 - DEBUG - Create Let's Encrypt SSL Cert for: domain. tld 30.06.2017-23:47 - DEBUG - Let's Encrypt SSL Cert domains: --domains domain. tld -- domains www. domain. tld 30.06.2017-23:47 - DEBUG - exec: /root/.local/share/letsencrypt/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https:// acme-v01.api.letsencrypt. org/directory --rsa-key-size 4096 --email postmaster@domain. tld --domains domain. tld --domains www. domain. tld --webroot-path /usr/local/ispcon fig/interface/acme You are running with an old copy of letsencrypt-auto that does not receive updat es, and is less reliable than more recent versions. We recommend upgrading to th e latest certbot-auto script, or using native OS packages. Saving debug log to /var/log/letsencrypt/letsencrypt.log Cert not yet due for renewal Keeping the existing certificate 30.06.2017-23:47 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-sc ripts/web1/.php-fcgi-starter 30.06.2017-23:47 - DEBUG - Enable SSL for: domain. tld 30.06.2017-23:47 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/ domain. tld.vhost 30.06.2017-23:47 - DEBUG - Apache status is: running 30.06.2017-23:47 - DEBUG - Calling function 'restartHttpd' from module 'web_modu le'. 30.06.2017-23:47 - DEBUG - Restarting httpd: systemctl restart apache2.service 30.06.2017-23:47 - DEBUG - Apache restart return value is: 0 30.06.2017-23:47 - DEBUG - Apache online status after restart is: running 30.06.2017-23:47 - DEBUG - Processed datalog_id 113 30.06.2017-23:47 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispcon fig_lock finished.
I doubt that the log level is causing this. Probably you did not execute the server.sh script as root on the shell with log level off, so the difference is that you execute the script and not the log level. ensure that you enabled the server.sh cronjob in the root crontab again and that the cron daemon of your server is running at all.
1. Log level set to debug. 2. Wait one minute 3. Disable the server.sh cronjob 4. Run /usr/local/ispconfig/server/server.sh 5. Active LE in websites in ISPConfig 6. Run /usr/local/ispconfig/server/server.sh Log: 02.07.2017-11:41 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 02.07.2017-11:41 - DEBUG - Found 1 changes, starting update process. 02.07.2017-11:41 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_update'. 02.07.2017-11:41 - DEBUG - Calling function 'update' from plugin 'apache2_plugin' raised by event 'web_domain_update'. 02.07.2017-11:41 - DEBUG - Verified domain subdomain . domain . ltd should be reachable for letsencrypt. 02.07.2017-11:41 - DEBUG - Create Let's Encrypt SSL Cert for: subdomain . domain . ltd 02.07.2017-11:41 - DEBUG - Let's Encrypt SSL Cert domains: --domains subdomain . domain . ltd 02.07.2017-11:41 - DEBUG - exec: /root/.local/share/letsencrypt/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v01.api.letsencrypt.org/directory --rsa-key-size 4096 --email postmaster@subdomain . domain . ltd --domains subdomain . domain . ltd --webroot-path /usr/local/ispconfig/interface/acme You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages. Saving debug log to /var/log/letsencrypt/letsencrypt.log Obtaining a new certificate Performing the following challenges: http-01 challenge for subdomain . domain . ltd Using the webroot path /usr/local/ispconfig/interface/acme for all unmatched domains. Waiting for verification... Cleaning up challenges Unable to clean up challenge directory /usr/local/ispconfig/interface/acme/.well-known/acme-challenge 02.07.2017-11:41 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-scripts/web7/.php-fcgi-starter 02.07.2017-11:41 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/subdomain . domain . ltd.vhost 02.07.2017-11:41 - DEBUG - Apache status is: running 02.07.2017-11:41 - DEBUG - Calling function 'restartHttpd' from module 'web_module'. 02.07.2017-11:41 - DEBUG - Restarting httpd: systemctl restart apache2.service 02.07.2017-11:41 - DEBUG - Apache restart return value is: 0 02.07.2017-11:41 - DEBUG - Apache online status after restart is: running 02.07.2017-11:41 - DEBUG - Processed datalog_id 125 02.07.2017-11:41 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. folder /etc/letsencrypts/<folders> are filled with that subdomain . domain . tld certificates ans settings. No symlinks created
This happened to me as well after update from Debian Jessie to the v9. one. I no longer get symlinks created unless I enable debug mode and it starts working. Posted here: Forum/Post
Ok, and subdomain.domain.tld is the main domain of the website, so you have 'subdomain.domain.tld' in the domain field of the site? The main domain of a website must be accessible so that LE can create a cert for that domain, if it is unreachable, the SSL activation will fail.
Yes. subdomain.domain.tld is in domain field. I also have domain.tld set up. Same as in previous example.
Ensure that you updated to ISPConfig 3.1.6. then disable LE in the website, save, and then enable LE again.
Hi, using latest 3.1.13p1, same error. Certificates are correctly issued and saved (no letsencrypt problems), but no symbolic link is created into the website/ssl/ folder. Activating ispconfig debug loglevel, the following 4 lines are interesting: Mon Jun 17 11:32:02 CEST 2019 Cert not yet due for renewal Mon Jun 17 11:32:02 CEST 2019 Keeping the existing certificate Mon Jun 17 11:32:02 CEST 2019 17.06.2019-11:32 - DEBUG - Let's Encrypt Cert file: does not exist. Mon Jun 17 11:32:02 CEST 2019 17.06.2019-11:32 - DEBUG - SSL Disabled. [domain] Certificate has been correctly issued, valid and in place. Any Suggestion?
There is a bug in latest certbot versions which causes this. we implemented a workaround for this bug already, update ispconfig with ispconfig_update.sh command and choose 'git-stable' as update target.