Greetings, I've spent the day reinstalling, countless times, Debian 12 since in my past experience it is the only (deb) distribution that previously worked with ISPConfig 3.2 Patch x implementation of Let's Encrypt. Ubuntu 24.04.3 fails in addition to Debian 12 in the same way. I have reviewed and confirmed the settings as detailed in the permalink on the LE subject. The server is behind a NAT firewall, with static IP addressing and open firewall ports 80/443/8080/8081, so the recommended setting to skip the LE check should be enabled. However, the automated installer script has no flag/switch to set the skip LE check (feature request I guess) so it fails to apply the apparently issued LE cert. This is very frustrating! Code: 127.0.0.1 localhost 127.0.1.1 isp.example.com isp # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters The story goes like this. The automated installer goes about it's merry way and attempts to perform the tasks at hand. I have noticed that there must be some dead servers in the round robin DNS lists of various tools and are not trapped for self recovery, i.e., ISPConfig and PHP My Admin. I have quadruple validated the resolve configuration. nslookup is working fine and claims to be using 127.0.0.53 (the expected value). The local server hosts file named installation is proper with 127.0.1.1 fqdn hostname as demonstrated above. Automated installer execution command: Code: # wget -O - https://get.ispconfig.org | sh -s -- --use-php=8.3,8.4 --use-ftp-ports=40110-40210 --ssh-port=56221 --ssh-harden --unattended-upgrades=autoclean,reboot --debug --i-know-what-i-am-doing Some errors follow: Code: [WARN] Unexpected resolver response: Server: 8.8.8.8 (/lib/os/class.ISPConfigDebianOS.inc.php:1711) PHP Warning: file_get_contents(https://www.phpmyadmin.net/home_page/version.txt): Failed to open stream: Network is unreachable in /tmp/ispconfig-ai/lib/os/class.ISPConfigDebianOS.inc.php on line 263 PHP Warning: Undefined array key 0 in /tmp/ispconfig-ai/lib/os/class.ISPConfigDebianOS.inc.php on line 265 [ERROR] Exception occurred: ISPConfigOSException -> Command chown -R www-data:www-data '/var/lib/phpmyadmin' ; cd /tmp ; rm -f phpMyAdmin--all-languages.tar.gz ; wget https://files.phpmyadmin.net/phpMyAdmin//phpMyAdmin--all-languages.tar.gz 2>/dev/null && tar xfz phpMyAdmin--all-languages.tar.gz && cp -a phpMyAdmin--all-languages/* /usr/share/phpmyadmin/ && rm -f phpMyAdmin--all-languages.tar.gz && rm -rf phpMyAdmin--all-languages failed. (/ispconfig.ai.php:15) Snip from the Monitor/LE Log: Code: [Sat Dec 13 07:34:17 PM EST 2025] responseHeaders='HTTP/2 200 server: nginx date: Sun, 14 Dec 2025 00:34:17 GMT content-type: application/json content-length: 1066 boulder-requester: 2876563366 cache-control: public, max-age=0, no-cache link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index" replay-nonce: ovB7kxrMNQmlz3Xbnx42m9SK3IidXeqQqZ4ArxH54HSGPRSN5l4 x-frame-options: DENY strict-transport-security: max-age=604800 ' [Sat Dec 13 07:34:17 PM EST 2025] code='200' [Sat Dec 13 07:34:17 PM EST 2025] original='{ "identifier": { "type": "dns", "value": "isp.example.com" }, "status": "invalid", "expires": "2025-12-21T00:34:14Z", "challenges": [ { "type": "http-01", "url": "https://acme-v02.api.letsencrypt.org/acme/chall/2876563366/627121334556/ctqdzA", "status": "invalid", "validated": "2025-12-14T00:34:15Z", "error": { "type": "urn:ietf:params:acme:error:connection", "detail": "99.x.x.85: Fetching http://isp.example.com/.well-known/acme-challenge/Pls5HUJIcI0YGfnw3mVw6CfUqCEe_EqUaE2828QKHyI: Connection refused", "status": 400 }, "token": "Pls5HUJIcI0YGfnw3mVw6CfUqCEe_EqUaE2828QKHyI", "validationRecord": [ { "url": "http://isp.example.com/.well-known/acme-challenge/Pls5HUJIcI0YGfnw3mVw6CfUqCEe_EqUaE2828QKHyI", "hostname": "isp.example.com", "port": "80", "addressesResolved": [ "99.x.x.85" ], "addressUsed": "99.x.x.85" } ] } ] }' Normal for me post installation configuration tricks: Code: # mysql -u root ALTER USER 'root'@'localhost' IDENTIFIED BY 'my strong password'; use dbispconfig; UPDATE sys_user SET passwort = md5('my strong password') WHERE username = 'admin'; quit; Replace the password to match the root password setting above # nano /usr/local/ispconfig/server/lib/mysql_clientdb.conf $clientdb_password = 'my strong password' Without modifying the password, future calls to ispconfig_update.sh --force will fail, upgrades inclusive. Set pureftp to advertise the public ip: # echo "99.x.x.85" > /etc/pure-ftpd/conf/ForcePassiveIP Fix postfix to receive/send local isp.example.com email: # nano /etc/postfix/main.cf Remove <machine.name> from "mydestination" Excerpt of ispconfig_update.sh --force Code: # ispconfig_update.sh --force >> Update Please choose the update method. For production systems select 'stable'. WARNING: The update from GIT is only for development systems and may break your current setup. Do not use the GIT version on servers that host any live websites! Note: On Multiserver systems, enable maintenance mode and update your master server first. Then update all slave servers, and disable maintenance mode when all servers are updated. Select update method (stable,nightly,git-develop) [stable]: Downloading ISPConfig update. Unpacking ISPConfig update. >> Update Operating System: Debian 12.0 (Bookworm) or compatible This application will update ISPConfig 3 on your server. Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]: Creating backup of "/usr/local/ispconfig" directory... Creating backup of "/etc" directory... Creating backup of "/root/.acme.sh" directory... Creating backup of "/etc/letsencrypt" directory... Checking MariaDB version 10.11.14 .. OK Checking ISPConfig database .. OK Starting incremental database update. Loading SQL patch file: /tmp/update_runner.sh.49kgNRx2Nf/install/sql/incremental/upd_dev_collection.sql Reconfigure Permissions in master database? (yes,no) [no]: Reconfigure Services? (yes,no,selected) [yes]: Configuring Postfix Configuring Dovecot Configuring Spamassassin Configuring Rspamd Configuring Getmail Configuring BIND Configuring Pureftpd Configuring Apache Configuring vlogger Configuring Apps vhost Configuring Jailkit Configuring AppArmor Configuring Ubuntu Firewall Configuring Database Updating ISPConfig ISPConfig Port [8080]: Create new ISPConfig SSL certificate (yes,no) [no]: yes Checking / creating certificate for isp.example.com [Sat Dec 13 09:52:16 PM EST 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sat Dec 13 09:52:16 PM EST 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 Discovered acme.sh version 3.1.3 with certificate home /root/.acme.sh Using certificate path /root/.acme.sh/isp.example.com_ecc / /root/.acme.sh/isp.example.com_ecc/isp.example.com.cer ISPConfig currently is using a self-signed certificate. Using apache for certificate validation [Sat Dec 13 09:52:23 PM EST 2025] isp.example.com: Invalid status. Verification error details: During secondary validation: 99.x.x.85: Invalid response from http://isp.example.com/.well-known/acme-challenge/E5KJJpl4XLq0XuUQUqkMzbRvBRpqjgq3DZRreevXsZA: 403 [Sat Dec 13 09:52:23 PM EST 2025] Please check log file for more details: /var/log/ispconfig/acme.log Issuing certificate via acme.sh failed. Please check that your hostname can be verified by letsencrypt Could not issue letsencrypt certificate, falling back to self-signed. At this point, I must complete the self-signed prompts to apply a new cert or the installation is broken! Also, I created a client, then a website and requested a cert and the process also fails, so once the main application (server process) fails, the demonstrated behavior is that all cert requests fail. I think is obvious that I'm not a NOOB with ISPConfig. I really need some expert help to solve this recurring Let's Encrypt problem. I've lost sooo much time... Thanks.
The installer does not need such a flag, as it does not perform this check. And your output shows that LE itself fails, not the ISPCofig installer or any check performed by ISPConfig. You clearly have network issues, not related to ISPConfig, maybe problems with IPV6 and you tested IPv4 only? Okay, so you don't have an issue with ISPConfig, but LE seems unable to reach your server from outside to verify certs. You can test the way acme.sh validates your server manually like this: echo 'hello' > /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/hello.txt You must then be able to reach http://isp.example.com/.well-known/acme-challenge/hello.txt from outside as .well-known/acme-challenge/ is a global alias to the directory /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/ in your web server. The likely reason for your issues lies in your NAT router or a firewall in front of your server here.
Code: root@isp:/usr/local/ispconfig/interface/acme/.well-known/acme-challenge# echo 'hello. Till said this must work and it does. No issues with the firewall passing HTTP tcp port 80 traffic!' > /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/hello.txt What else can I try?
Check the error and access.log of your web server, maybe you will find some additional details on why you get a 403 error when LE tries to validate the cert. if you can't find the 403 errors in the logs, then you might be using a proxy or firewall that blocked the request. Also, as a general note, if you e.g. would be using CloudFlare, then you can not use Let's Encrypt as they block any request in proxy mode.
Till, Thanks for the suggestions but the are not producing anything more to trouble shoot. Cloudflare DNS is not being used so the proxied DNS does apply to this issue. To put to rest the whole firewall blocking assumption, I have run tcpdump to capture the port 80 traffic and it does indeed capture the complete tcp conversations as expected. I have captured the ispconfig_update.sh --force conversations and to the best of my rusty ability review of the content in Wireshark's graphical interface, everything looks normal. However, I have not studied any of the inner workings of the Let's Encrypt process nor the ISPConfig processing of the payloads. It is abundantly clear that the traffic is passing. As a side note, when running the update --force, the permalink suggestion of ticking on the skip LE check is reverted to unchecked. I have reenabled it for the next test to obtain a client hosted website. When configuring a client hosted website and requesting a certificate, the process also fails. I have pcap captures of that conversation too. When looking at the text based apache2 log files error and access, I do not find anything to further investigate as root cause. If there are specific log files that should be reviewed, please supply their location and name(s). It's confusing to me that the Let's encrypt payloads find the public IP Address association and further report it. It is an identical match! I'm uploading sanitized text representations of the pcap files for your review. Code: tcpdump -nn -A -i ens33 port 80 -w tcp_port_80-ClientCertRequest-01.pcap Thanks for the continued support! EDIT: Uploaded the acme log as backup to the pcap captures.
