Using LetsEncrypt with own domain

[SweetAction]

Hello All,
In the past, if you wanted to use 3CX's implementation of an ACME client with LetsEncrypt, you had to use their managed domain. If you wanted to use your own domain, you had to use your own SSL cert.

The CA Forum recently voted to lower cert lifetimes from 397 days (13 months) to 200 days and down to 47 days by 2029. In light of this, my question is:

For companies using their own FQDNs...
Does 3CX have any plans to allow their ACME client to handle the certs?

I can of course script in my own ACME client and script to update the cert, however that would make installations unsupported and I rather not. However, if you have a solution you've been using, I'd love to hear it (even if just via PM) because I don't really want to reinvent the wheel if I don't need to.

 

[fxbastler]

Hello @SweetAction,

We currently use own FQDNs with Let’s Encrypt certificates for all 3CX systems of our customers. The certificates are all managed outside of 3CX (centrally on the firewall, usually pfSense with the ACME client and HAProxy as the backend with a Lua script for renewal). At the time they become eligible for renewal, they are automatically renewed there, then deployed to the 3CX via SSH and automatically activated.

For this purpose I published a script here in the forum years ago which still works to this day and is regularly linked in the forum. If, as announced, the period of validity and the possible renewal window are reduced, this has no impact on the use of our 3CX's. It simply happens more frequently.

The only adjustments on the 3CX are:

1. we set up a dedicated user with limited privileges and a key for passwordless SSH access in order to upload the certificates from the firewall to the 3CX
2. we have a shell script on the 3CX that is executed via a cron job as root which installs the renewed certificates when required.

This has been running unchanged for years from the very beginning on all installations. It does not break 3CX support and can also be easily removed if that is desired (I don't know why).
If a 3CX has to be completely reinstalled, then the SSH user, its permissions, the cron job, and the script must be set up again. However, since everything is always the same except for the password and the key, the effort required in such a case is very small and is done in minutes.

 

[SweetAction]

Hello @SweetAction,

We currently use own FQDNs with Let’s Encrypt certificates for all 3CX systems of our customers. The certificates are all managed outside of 3CX (centrally on the firewall, usually pfSense with the ACME client and HAProxy as the backend with a Lua script for renewal). At the time they become eligible for renewal, they are automatically renewed there, then deployed to the 3CX via SSH and automatically activated.

For this purpose I published a script here in the forum years ago which still works to this day and is regularly linked in the forum. If, as announced, the period of validity and the possible renewal window are reduced, this has no impact on the use of our 3CX's. It simply happens more frequently.

The only adjustments on the 3CX are:

1. we set up a dedicated user with limited privileges and a key for passwordless SSH access in order to upload the certificates from the firewall to the 3CX
2. we have a shell script on the 3CX that is executed via a cron job as root which installs the renewed certificates when required.

This has been running unchanged for years from the very beginning on all installations. It does not break 3CX support and can also be easily removed if that is desired (I don't know why).
If a 3CX has to be completely reinstalled, then the SSH user, its permissions, the cron job, and the script must be set up again. However, since everything is always the same except for the password and the key, the effort required in such a case is very small and is done in minutes.

This script I assume?
https://www.3cx.de/forum/threads/eigener-fqdn-aktuelle-anleitung.116778/post-413680

 

[VoIPTools]

I've been looking at this challenge too. Keeping things stupid simple is highly valued. Having a front end proxy that supports automatic Let's Encrypt rotation is a common feature, but having a proxy in front of NGINX seems duplicative. I'm looking at this more for our VoIPTools suite of tools so perhaps my thoughts are not specific to 3CX. However, I have tried several different proxies including NGINX Proxy Manager, but they are all more complicated than I would like. YARP is a stupid-simple proxy, but it doesn't implement certificate automation. Here is the thing... it is not enough to just update the certificate, you have to ensure your proxy or NGINX is aware that the certificate has been updated. That's not all that straightforward with web servers like Kestrel. I guess my point is I agree with @SweetAction that it would be really nice if we could leverage the work 3CX has already done when using our own FQDN.

 

[fxbastler]

This script I assume?
https://www.3cx.de/forum/threads/eigener-fqdn-aktuelle-anleitung.116778/post-413680

this one:
https://www.3cx.de/forum/threads/ssl-certificate-erneuert.114018/post-441718

 

[fxbastler]

Keeping things stupid simple is highly valued.

agree

but having a proxy in front of NGINX seems duplicative

It's only obsolete if it's not absolutely necessary - which is often the case since the customer only has one public IP address, several other services run over TCP port 443 and the mere fact that SNI is required for a request already protects against simple script kiddies and mass scans if they don't know the FQDNs managed by the proxy.
I had a conversation with a sales partner today precisely about this behavior as their 3CX server has to block dozens of IP addresses daily due to such simple scans and it spams their logs. Our logs shows no activity in this regard.

Here is the thing... it is not enough to just update the certificate, you have to ensure your proxy or NGINX is aware that the certificate has been updated.

right; in PfSense (and others) done automatic with ACME client and i.e. haproxy or squid ...

 

[SweetAction]

but having a proxy in front of NGINX seems duplicative.

Agreed, but his script is exporting the cert and installing it directly into 3CX, not just proxying it. You could use his script without actually reverse proxying the connection.

Thanks @fxbastler for the feedback that you've done the "script in my own ACME client / cert renewal process", I just want to know if anyone else has another way of doing this and if 3CX has any official statement on this.

 

[mOrbo]

I also have the same question. From my side (Customer) it's a shame that 3CX is not able to provide a proper and simple integrated Lets's encrypt solution for own FQDNs since years.

The script is nice and I will test it, but now it should be a main goal for 3CX to implement a proper integrated and easy solution for the customers.

 

[VoIPTools]

First, making changes to Nginx is not supported. However, there is a new Nginx plugin (currently experimental) that automates Let's Encrypt renewals. If I were to guess, perhaps in future versions of 3CX they will leverage this feature and then it becomes much easier to set this up for your private FQDN? Let's see...