I have already been mucking around with this. I’ve automated LE with my DNS servers already so I’m just looking how to FreePBXize it. Which, of course, has to account for the technical debt which may require other things to be touched.
acme.sh has dnsapi/dns_namecheap.sh, also when issuing certs it has the --days option. IWFM
Let’s Encrypt has a maximum expiry of 90 days while ache.sh defaults to 60 days. Meaning it would try to renew the cert 30 days before expiry.
Is that a problem?
The acme.sh cron job runs every day and if the cert being checked is tagged for 42 --days then it will be renewed on that period, the default CA used by acme.sh is not LetsEncrypt but https://acme.zerossl.com/v2/DV90, you can add --server and --set-default-ca if you don’t want that
Your domain DNS entry has to be updated only once with a delegated control of the _acme-challenge subdomain to the ACME DNS service.
Blockquote
Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone
Blockquote
This solution, much like the rest, requires you to use a specific DNS supplier for this to work. That means you will need to create an account acme-dns.io and set it up with API access just like the other providers.
The only difference here is you’re using their service for a CNAME record instead of the entire zone file. It would still need to be treated just like using any other DNS provider API.
Be careful to not conflate the acme protocol with LetsEncrypt (which is a CA) and the acme client embedded in FreePBX
Cert management is changing a lot in the wider world; so, yes, we are planning updates to the process in FreePBX. The DNS request seems reasonable. But, one might consider that if you are in control of your TXT records, then you are (maybe) also in control of the service(s) which are (not) sharing port 80. So OP’s case is somewhat unique and might lend itself to other solutions instead e.g. an NGINX proxy to re-direct incoming port 80 traffic based on the domain or user agent.
1 Like
I actually have nginx reverse proxy and I tried to use it to handle port 80 for lets encrypt and it failed.
When i use NAT to forward port 80 directly to FreePBX it works with Let’s Encrypt flawlessly, but if use nginx reverse proxy which forwards connection to FreePBX it does not work.
I use same method to forward port 80 to other internal services via nginx reverse proxy (not for Let’s Encrypt usage) and it works fine. But fith FreePBX and Let’s Encrypt, it does not work.
It may be I fail to set something properly. I could not find any example or tutorial how to do it using nginx proxy.
It would all be much easier if there is not that silly requirement for port 80.
It’s not a silly requirement. Port 80 is one which the central management of an organisation would normally control over. It’s much easier for a hacker to spoof an official user if they have free choice of port number.
LetsEncrypt has weak authentication at the best of times, compared with a premium certificate, and certificates are about authentication, not encryptiong. They are important to secure access because there is no point in having an encrypted connection if it is actually to the attacker, acting as a man in the middle.
I never went to deep into this topic but I guess if I already have valid certificate I can use it as proof of control to get renewal, and I do not need nothing more. the only issue would be if certificate expires as then it could not be used as a proof.
Requirement for port 80 basically means you have to obtain public IP for each service you want to use with Let’s Encrypt, expect for simple services like web server that can be handled using reverse proxy which would then handle certificates on their behalf.
Problem with FreePBX is that it needs to get certificate for itself because it is used for other stuff, not just for web so it cannot relay on reverse proxy.
But this is going out of scope of this discussion. This is about how to deal with existing functionality and limitations.
I am even thinking if it is possible to make FreePBX do knock knock to the firewall indicating it needs port 80 so firewall would temporarily redirect port to FreePBX and after certification is done, it returns port 80 for to it’s regular use.
freepbx 14 was such a bliss
you set up and use acme.sh from outside freepbx, and it just works, no manual interventions or i understand dns manual blah blah command options, but we run all our own dns servers.
this is using acme.sh NOT the useless clusterf##k that is certbot
Just to remind everyone, this thread is about DNS-01, but DNS-01 does not use port 80 (HTTP), it uses port 53 (DNS) 
, acme.sh can swing that way but I don’t think the current freepbx acme client can as it relies on HTTP being on port 80
Also to remind everyone, we’re talking about Linux boxes here. You are not being forced to use FreePBX’s web interface for everything. There’s nothing stopping you from running acme.sh on the server, configured to do whatever challenges you want (as we do on all our managed PBXs.)
Also also to remind everyone. Not every user/admin of a FreePBX systems has the knowledge or skillset to go in a fire off Linux commands, install things or have a strong Linux background. In some cases doing things completely in the GUI is how they do things.
The whole “just do it all outside for FreePBX because that’s what I do” doesn’t apply to a large subset of the user base.
Then your answer to the OP (or large subset of users) would be something like " No that’s impossible to do" ?
No, I didn’t say that at all. It seems you’ve missed my earlier statements in this thread:
So no this isn’t impossible to do but it will require updating things in FreePBX with the certificate manager module and maybe in a few other places. Along with that, since there are major changes coming down the line for TLS over the next three years perhaps we would also want to look at API support for other TLS vendors so certs can be updated automatically since the expiry times are dramatically dropping in the next three years.
That sounds to me that so far you “did it outside of FreePBX”.
Updating FreePBX’ certs is trivial with acme.sh’s renew hook and a couple fwconsole cert {command}s , acme.sh can be set to renew certificates from 1 day to lots of days, you are not limited to using LE or certbot.
With DNS-01, there is no need to even have FreePBX involved at all
Yes, for my own infrastructure not a random FreePBX. My point was I could take that and push it into FreePBX.
Except for the management of the cert to assign it to the GUI or provisioning or TLS for endpoints. So from the admin perspective of managing the certs, seeing when they renew or choosing a provider to use with the automation, yes FreePBX is involved. Also being able to back up and restore said certs via the Backup/Restore module.
Then I look forward to your contribution.