Updating certificate, completely breaks FreePBX

I used to use the default LetsEncrypt for certificate management. This really became a serious problem last year, as the updater stopped working. I think it was using the IP address instead of the FQDN to access port 80.

Anyway, I run PFSense on the frontend. PFSense is configured to setup certs for all my services, including Voip. I configured actions on PFSense to push the cert down to FreePBX. Simple. It did in fact push the cert to FreePBX, and it all looks good. Except, when I update the cert on FreePBX, everything goes down. SIP still works, but all RTP media traffic stops cold. i went through every single page of FreePBX configs to try and find where that would affect PJSIP traffic, but I have not found anything. I’m using SIP on 5060 from Twilio, no certs involved in that traffic at all. Yet, when I update the certificate, ALL incoming traffic from Twilio has no media at all, no audio either way, and the call drops at 32 seconds.

In summary, what I want to do is configure the cert on PFSense, push it to FreePBX.
These are the actions that trigger on PFSense to push the cert to FreePBX.

scp -i /root/.ssh/id_rsa /conf/acme/voip.aquilatech.com.fullchain [email protected]:/etc/asterisk/keys/voip.aquilatech.com.crt

scp -i /root/.ssh/id_rsa /conf/acme/voip.aquilatech.com.key [email protected]:/etc/asterisk/keys

ssh -i /root/.ssh/id_rsa [email protected] “chown asterisk:asterisk /etc/asterisk/keys/voip.*”

ssh -i /root/.ssh/id_rsa [email protected] “fwconsole certificates --import”

ssh -i /root/.ssh/id_rsa [email protected] “fwconsole certificates --default=voip.aquilatech.com

That all works fine, the problem is on FreePBX, after the cert is updated, no more audio EVER, until
I restore from backup.

That’s interesting insofar as unless you are using TLS for your SIP transport, there are no certification used in calls and never for media even if using SRTP, Generally the certs in /etc/asterisk/keys and /etc/asterisk/keys/integration are used for the webserver, TLS or whatever.

The id_rsa identity is not a ‘certificate’ and needs to be in the .ssh directory of the asterisk user’s home directory, not ./keys

I find

GitHub - acmesh-official/acme.sh: A pure Unix shell script implementing ACME client protocol

is an excellent tool for issuing certs and maintaining them directly within the FreePBX host, with ‘hooks’ to match most any deployment.

rsa_identity is the login that scp and ssh use to communicate with FreePBX. That stuff all works perfectly.

The problem is strictly with Freepbx. when the cert is changed or deleted, there is no more RTP traffic at all. Including on trunks that do NOT use TLS at all.

You can eliminate those actions from the problem entirely. Just go to Freepbx and delete the voip certicate. Immediately all telephony is broken.

And that is the interesting part, no part of FreePBX handling SIP or RDP negotiated connections reference the ‘certs’ apart from TLS connections. Does anything on your router change ?

nothing changed on router.
What I noticed on the firewall is there are NO inbound packets from Twilio, after I delete that cert. The SDP seems correct, but no RTP arrives.
And the Twilio trunk is just plain 5060 with no TLS.
I spent at least 20 hours going over every detail and I’m stumped.

We are having to just live with the expired certs.

To what endpoint does the twilio trunk point to, IP or URL? Which ‘firewall’ is the traffic not arriving at?

I was watching my edge firewall, saw the SIP invite, expected RTP media, but nothing arrived.

Anyway, I was delayed in responding because I think I found the issue, and I just tested it and it’s working now! I went through all the conf files and I found something I put in pjsip.transports_custom.conf with a hard coded certificate filename. When my new firewall updated the cert, this is where it broke. I changed the actions on the acme updater and now calls are working. Still verifying the acceptance of the certificate on my remote users…

I hope this has removed the job to “automatically update” the legacy LetsEncrypt certificate. I think it has.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.