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