ISPConfig3 Test server issue: LetsEncrypt and private IPs behind UDMSE

Disclaimer : I know LE doesnt support private IPs... so I've been trying some networking magic to expose just enough of my test server to a public IP to get a cert... I'm close, but not quite there

I have a couple full blown ISPConfig3 systems running in a datacenter, with a pair of secondary DNS servers. Both are running 3.2.11p2. (Yes, I realize a new release is available, but all is happy with the world so I'm not in a hurry to change it). The Main server with my "target" TLD contains a purchased domain, and that domain has a CAA record permitting LetEncrypt to issue certificates against it. It has allowed the secondary server to issue a LE cert against the target domain (both are fully self contained systems).

I have another server at home, behind a my ISP's router and my Unifi DreamMachine SE. The UDM is exposed with a public IP, and provides LAN services to a number of systems inside my home, including a test system for my main server. (The UDMSE has a decent IDS/IPS - its not perfect, but its a lot better than the ISP router ever was)

I have exposed the Test server (Port 8080) to the public IP, and can confirm that when I access the test system ISPConfig login page (I am using an nginx reverse proxy to do name based forwarding), I am getting to the test system. However, I'm unable to convince the test system that it is exposed to the public IP. When I perform an ispconfig_update.sh -force i get:

Code:

Server's public ip(s) (public.ip) not found in A/AAAA records for ispconfigtest.server.com: 192.168.1.247

and the install/update creates a self signed certificate, that Chrome complains about (yes, I know I can use Firefox and ignore it, but my userbase is mainly Chrome so I must get Chrome working)

I have no definition of the internal IP other than the IP definition of the server itself. In attempting to work about this, I have tried forcing a definition of the test server on the UDMSE, and on my internal pihhole server, but the ISPConfig system itself seems to be the primary source of truth on what 'ispconfigtest.server.com' resolves to.

So my question is:

What can I change on the Debian 12 server that will allow the the acme process to identify that it's exposed to the outside world, without screwing up the ISPConfig installation?

(I'm really hoping not to have to get a wildcard SSL cert just to deal with this... there has to be a way)

 

You do not need to obtain LE SSL certs for the web server and any domains inside it if you have an nginx proxy manager infront of them. Just use that NPM to obtain LE SSL certs for each of them.

 

Why not tinker with acme settings to use dns authentication?

That is, if you're requesting a certificate for a hostname under a self dns hosted domainname.
Or if dns is hosted by a 3rd party theymay be supported too. Acme has tons of different dns plugins.

Then you don't need to expose your server in any way.

 

Unfortunately from what i can see, NPM isn't able to update the ispconfig server hosting my TLD. This isn't a dynamic dns situation (I have a domain at cloudflare where I do just what you suggest)

That was my first thought but I couldn't figure out a way to get NPM to interface with the ispconfig dnsmanager...

(Unless I've missed some additional option in the docker container?)

 

That is what I'm asking about... some way to get Acme to work in this technically unsupported configuration while still retaining ispconfig functionality. I really don't need(or want if possible) the server exposed but LE needs it exposed under the current issue/renew methods.

Do you have any suggestions/configurations in mind? I'm thinking that if theres a viable method that doesn't require my network foolery it could become part of the basic ispconfig install when installing on a non-routable address.

Wouldn't that be nice

 

Are you using acme.sh or certbot?
And are you dns hosting your domainname yourself on your full blown ISPConfig3 systems?

If acme.sh and self hosted dns, you can use 'dns_ispconfig' within acme.sh on your private system to authenticate your request.
There are several tutorials out there on how to configure ISPC to allow remote dns updates (through acme.sh's ispconfig plugin on your private system in this case).
Add this in /root/.acme.sh/account.conf on your private system:

Code:

ISPC_User='<ispc user>'
ISPC_Password='<ispc pass>'
ISPC_Api='https://<ispc url>/remote/json.php'
ISPC_Api_Insecure='0'

If I understand correctly you're trying to request a certificate for the hostname of your private ISPC system?
Run this command manually to request the certificate:

Code:

acme.sh --issue --dns dns_ispconfig -d <hostname> --keylength 4096 --key-file "/usr/local/ispconfig/interface/ssl/ispserver.key" --fullchain-file "/usr/local/ispconfig/interface/ssl/ispserver.crt" --renew-hook "letsencrypt_renew_hook.sh"

Running ispconfig_update.sh afterwards should skip the certificate request part as there is a valid certificate present.

 

NPM server works on its own and cannot be made part of ISPConfig ecosystem. It will have its own web gui and it is on its own as a web server.

On the other hand, if you want to use your ISPConfig home server directly, you may do so by simply port forward all relevant ports to that server, instead of using NPM infront of it.

 

Yes, I'm hosting the domain on my full blown ISPConfig3 system, with 2 slave dns servers, and the test (standalone) system is using acme.sh

Your suggestion has indeed allowed for a successful LE cert to be issued, Thank you! (I had to --force it --- I guess previous attempts had left some garbage in the system) for the main ispconfig3 install. (I've not yet disabled the network foolery, but I suspect that will be no issue now that the DNS validation is happening on the mail server)

However I'm still having problems with issuing certs on sites within the config (they are also part of the same TLD). Is there an
"options" variable I can set in the account.conf that will always force the use of dns_ispconfig?

 

Sadly, so - I have more than just this one server/port set coming through, thus my need for NPM and name based routing.

 

Well, I guess that is common for a single public IP, be it static or dynamic, with multiple servers behind it.

As an alternative to using NPM infront of ISPConfig servers, you may also use ISPConfig web server too, to be / manage the same.

And, by doing that, you may write some scripts on your ISPConfig home servers so that they can automatically detect any website creation and create a proxy vhost in that proxy server.

However, so far that I remember, this has never been attempted by anyone, may be due to its complexity, or since mostly people will use vps that is each assigned with its own public IP.

Though, there were some efforts in the ISPConfig git, which you can learn from, to enable dual web servers in an ISPConfig with one being a proxy to another, but I have not been following it, so I did not know its current status.

Sorry, that are just some vague ideas from me that may or may not be useful.

 

That's because ISPC still uses web authentication for websites.

You have 2 options:

1) Manually request the certificate using this command:

Code:

acme.sh --issue --dns dns_ispconfig -d <domain.tld> --always-force-new-domain-key --keylength 4096 --key-file '/var/www/clients/client<id>/web<id>/ssl/<domain.tld>-le.key' --fullchain-file '/var/www/clients/client<id>/web<id>/ssl/<domain.tld>-le.crt' --reloadcmd 'systemctl force-reload apache2.service' --log '/var/log/ispconfig/acme.log'

Afterwards you enable SSL and Let's Encrypt in ISPC. Acme.sh's cronjob will handle renewal.

Keep in mind when you change anything certificate related afterwards, like adding an alias, ISPC will change /root/.acme.sh/<domain.tld>/<domain.tld>.conf to use web authentication again.

2) Change /usr/local/ispconfig/server/lib/classes/letsencrypt.inc.php:
On Ubuntu 24.04 this is line 77:

Code:

$cmd = 'R=0 ; C=0 ; ' . $letsencrypt . ' --issue ' . $cmd . ' -w /usr/local/ispconfig/interface/acme --always-force-new-domain-key --keylength 4096; R=$? ; if [ $R -eq 0 -o $R -eq 2 ] ; then ' . $letsencrypt . ' --install-cert ' . $cmd . ' --key-file ' . escapeshellarg($key_file) . ' ' . $cert_arg . ' --reloadcmd ' . escapeshellarg($this->get_reload_command()) . ' --log ' . escapeshellarg($conf['ispconfig_log_dir'].'/acme.log') . '; C=$? ; fi ; if [ $C -eq 0 ] ; then exit $R ; else exit $C  ; fi';

Change it to:

Code:

$cmd = 'R=0 ; C=0 ; ' . $letsencrypt . ' --issue ' . $cmd . ' --dns dns_ispconfig --always-force-new-domain-key --keylength 4096; R=$? ; if [ $R -eq 0 -o $R -eq 2 ] ; then ' . $letsencrypt . ' --install-cert ' . $cmd . ' --key-file ' . escapeshellarg($key_file) . ' ' . $cert_arg . ' --reloadcmd ' . escapeshellarg($this->get_reload_command()) . ' --log ' . escapeshellarg($conf['ispconfig_log_dir'].'/acme.log') . '; C=$? ; fi ; if [ $C -eq 0 ] ; then exit $R ; else exit $C  ; fi';

IMPORTANT: This change will be overwritten when ISPC is updated!
Change it again after the update.

 

Yes, That's what I surmised after reading the logs

I did some fiddling last night and found that line, but placed my change after the --issue... which didn't work as intended. Glad to know I was on the right track despite being half asleep.

Your change is working perfectly. I had retained the -w parameter, which was throwing it for a loop, and causing it to revert to the well
known directory validation despite the presence of the --dns dns_ispconfig but once that was removed per your change, it works perfectly.

Having to reapply the change after updates is a minor inconvenience in the scope of the benefit provided.

Thank you so much for the help!

 

Actually it was installing a self-signed cert.

Thanks for the idea, but I'm trying to hide this server behind my UDMSE. I have Nginx Proxy Manager to handle the name based routing inside my LAN already configured for other purposes that I'm going to piggyback on.

 

That is not exactly correct, since you need that NPM to actually be infront rather than behind the UDMSE, so what I and @till mean is that an ISPConfig web server can be and manage the same just like that NPM.

You can piggyback the same just like an NPM server, with the possibility of multiserver setup as well, whether separate ISPConfig servers in the home network from the one in the datacentre or link them all.

Well, at least I think that are possible and have their own advantages but I could be wrong though.