Recommended method of renewing certificates automatically?

E

EnableServices

New Member
Jan 6, 2026
4
1
3
21
Hello

I wonder if someone could provide me with the best practice or built in methods, for renewing certificates used in FusionBPX?

I generated the original certificate using the script located here: /usr/src/fusionpbx-install.sh/debian/resources/letsencrypt.sh, which worked perfectly and generated the certificate.

I have seen on numerous posts on here people saying that it should have created a cron for dehydrate to renew however having read through the script myself i don't believe it ever would have.

The certificate is for a standard singular domain not a wildcard.

Kind regards,

Thomas Burridge
 
  • Like
Reactions: francois
I'm fairly certain you can just re-run the renewal command in a cronjob, I guess every day.

/usr/local/sbin/dehydrated --cron --config /etc/dehydrated/config
 
Many thanks @some1has2 @hfoster that's great. If TLS is enabled for extensions, it looks like the sip internal profile needs to be reloaded too, and we were curious as to whether we'd missed something that does this in the setup.
 
Actually that's a really good point @markjcrane is there a documented way to reload sofia on TLS refresh that doesn't cause downtime? My server hasn't been running long enough to see this in the real world yet, but I am using TLS to my extensions.
 
  • Like
Reactions: EnableServices
My current understanding is that it requires a FreeSWITCH restart. It's certainly not ideal, maybe someone else knows a better way.
 
@markjcrane what's the cleanest reload command for freeswitch/fusion that should do it? I know there was a button in fusion status but I think something I can just throw on cron to just hard reload at midnight once per month would suffice for now since I'm operating generally in a single timezone atm ... i'll look at integrating better with the dehydrated tool in the future so it only does the reload when the cert actually changes, but let me know if you have ideas/plans there because really this should be part of base fusionpbx docs is setting up via those install scripts, running dehydrated commands, then adding a script to cron that runs dehydrated updates and then reloads freeswitch: having certs expire and debugging IT issues is such a bane, it's better to have a working process from the start, even if it is a bit brutal without a cleaner solution

@pbxgeek did you have a recommendation of SBC and associated reading before searching more? my earlier reading on the forums suggested that we really shouldn't need one with fusion at all, but I wanted to put in some redundancy here with a master-master DB and 2 servers running fusion so I can kick one offline and the other continues via DNS LB, so I'm right at the consider-an-SBC stage
 
The suggestions are correct. You don't need an SBC to run FusionPBX or FS PBX, but it does add some cool features and a small sense of peace of mind. Like easier handling of certificates and failover events. But it comes at a cost of more infrastructure buildouts. So it has to be worth it.

I have many clients with redundant servers, master-to-master replication, and no SBC. This can run you for a long time, depending on your volume. However, if you do decide to consider something in the future, look at open-source Kamailio or OpenSIPS.
 
  • Like
Reactions: EnableServices
@markjcrane I can see from Signalwire #2287 there is not going to be a soft way to reload, so it's going to be running the `fs_cli -x "sofia profile internal restart"` with a hard reload
but I'm still suggesting that you advise how you recommend this with dehydrated within your FusionPBX docs so the community knows the standard way and behaviour as the recommend links above say run dehydrated daily and aren't from your official docs, but you wouldn't want to restart this daily so maybe a mini script or wrapper would do best?
 
This is not a safe way to do this. When doing this, Sofia won't let go of the SIP port, and then it won't start up again because it will see it as the port is already being used.
fs_cli -x "sofia profile internal restart"
Click to expand...
So you would be better off restarting FreeSWITCH. When FreeSWITCH is restarted, it lets go of all connections, and then the port is not occupied, and it will be able to reuse the SIP port again.
 
  • Like
Reactions: EnableServices
For what it's worth, I've typically put a cronjob in the early hours of Sunday morning to restart freeswitch; primarily because of many historical memory leaks with freeswitch, stuck calls that remain in the core database, and for certificate renewals.... or if you're messing around with the sched_api like I was and accidentally left some stuff running indefinitely.

It is worth being around for that first reload though, just in case it doesn't come back.
 
markjcrane said:
This is not a safe way to do this. When doing this, Sofia won't let go of the SIP port, and then it won't start up again because it will see it as the port is already being used.
Click to expand...
Hmm is there a bug report around this in SignalWire? When I click the button in Status in Fusion or when I run the fs_cli command, it restarts TLS sofia without issues as is expected. The only time I've had a port issue was when I was changing ports in the profile and that did require a full restart.
 
You must log in or register to reply here.
Top Bottom