Automating Public Certificate Renewal for Audiocodes SBCs

In this post I like to highlight that a newer Audiocodes Mediant SBC release received an awaited feature to deal with shorter public trusted certificate lifetimes. As this is no brand new topic it is nevertheless very important for Teams Direct Routing administrators, SBC administrators, partners, managed service delivery, operation teams or else to keep this in mind and work on it. Public trusted certificates which are required will expire in a shorter period of time which means you have to renew these more often. This post provides a bit of background on the why and what you should strive for in the not so far away future.

Background

In April 2025, the CA/Browser Forum* approved Ballot SC-081 to reduce the maximum validity of public TLS certificates to 47 days. The key motivation is stronger security: shorter lifetimes limit the impact of compromised certificates, require more frequent validation of domain ownership, and help organizations prepare for future cryptographic changes. At the same time, the move encourages automated certificate management as the new industry standard.

*About the CA/Browser Forum: The CA/B Forum is a consortium of major web browser vendors (such as Apple, Google, Mozilla, Microsoft …) and public certificate authorities (including DigiCert, Sectigo, GlobalSign, Entrust …) Together, these organizations define and govern the trust standards for HTTPS and publicly trusted digital certificates across the internet.

Timeline to 2029

The reduction is planned to take place in three main stages:

March 15, 2026: Maximum validity drops to 200 days
March 15, 2027: Maximum validity drops to 100 days
March 15, 2029: Maximum validity drops to 47 days

Challenge with SBCs

One thing what must change is the certificate renewal process if it is manual today. It must be automated otherwise you, as an SBC admin, managed service provider or else need to renew certificates every 47 days in 2029+. That is not feasible. You had to go through the whole process manually every time and waste time with this. That’s why there are other options available but maybe not yet to each and every system which requires publicly trusted certificates. A while ago I read this post from describing the issue and urging the SBCs vendors to do something about it. And better sooner than later. It seems as his words – among others make aware of this – were read.

Automate renewal of publicly trusted certificates

To go from an manual to an automated process implies some effort to implement it but on the long run it will save you the time to renew certificates every 47 days for published services, like an certified Audiocodes Mediant SBC for Teams Direct Routing.

Let’s think a bit about it. What option could we have here? Well, you could develop a script, at least for exchanging certificates on the device but what about the process which must be completed on the public CA? I did not try this but this might be more complex to write a script walking through the public CA’s process (wizard) to renew a certificate if there is no API. It there is one it could be used. If not, well, I’d not like to develop a script doing the work on the – probably over time changing – website of the public CA’s website. Also there could be connectors available but this should be something provided by the vendor of the system you are using and nothing I would develop myself. Alright what else? AI, Agents? Huh? Not sure maybe an option but I did not really consider building an AI-based solution to cope with it, did you? If yes, feel free to share in the comment. I’d be interested to hear about it. Any more?

There we are: ACME. Probably many of you have read or heard about it? It’s nothing new. Maybe you heard or read about it if you used Let’s encrypt certificates or else for specific test systems?

ACME (stands for Automated Certificate Management Environment) is a protocol that automates the lifecycle of TLS certificates, including issuance, validation, and renewal. As certificate validity periods become shorter, ACME helps organizations replace manual processes with automated and reliable certificate management, making large-scale certificate operations feasible. And this was added to newer Audiocodes SBC releases. But wait not just update or upgrade to it. Read the docs first and prepare for it. 😉 ACME is just one capability among many others. I also would strive for a long-term instead of a latest release.

Audiocodes Mediant 7.60A.300.042 gets ACMEv2

As far as I found out I the Audiocodes Mediant SBCs received ACME with version 7.60A.300.0042. But not only that’s why you need to check to which version you might want to go, if your current public CA provider is supporting ACME and so on. Because it does the expected benefit if you go to a newer version but your process to procure public trusted certificates does not allow you to use ACME because you do not purchase certificates directly.

In other words, you should check first if you are able to use ACME not just on the Audiocodes SBC but also the procurement and delivery process etc. for such publicly trusted certificates etc. If you directly obtain certificates from such public CAs it should not be a big deal but if not you might need to change this if you like to benefit from ACME instead of manually renew certs every 47 days in 2029+. But basically if you do the math on this automation will be the way to go. I mean anyway, standardized and automate as much as you can there will always be enough other stuff to do.

If you Mediant SBC supports ACME and the other key prerequisites are satisfied you can, as an Security Administrator, configure an account, an ACME profile, the TLS context etc. It is very well documented. You can decide between HTTP-01/DNS-01 domain validation challenge. However the DNS-01 challenge requires you to allow the device, SBC ACME service to access your DNS (services) which is currently only tested and supported with Azure DNS as far as I understood correctly. So the HTTP-01 challenge remains which is used by a specific file on the web service so that the public CA can verify that the system is triggering the renewal is allowed to do so by showing the file.

As implementation details may change between firmware releases, administrators should refer to the latest Audiocodes documentation when planning deployment. Also watch out if this is supported for what your scenario, because currently, at the time of writing this, 7.60A is neither a recommended nor supported version as an certified Teams Direct Routing SBC.

Conclusion, opinion and summary

To me this was an overdue feature to arrive in SBCs. I do not know anyone who likes to renew certificates. I mean I don’t mind but there no one I can imagine who really likes this task no matter for what system. So, finally being able to (soon) automate it by using nativ tools without using any scripting magic is nice and a must-do! As a next and first step I would check where the public trusted certificates are purchased and so on. Also if you use a wildcard certificate which might change the situation a little because you might not want the SBC to trigger the cert renewal process first? So important to check this thoroughly, align with other systems which require public trusted certificates and find the way that works for you and your organization.

I did not mention this above but depending on your organization’s size you might take a look on third-party services, if not done yet, which might also could add value in more complex scenarios. Just to name a few but these are no recommendation, no advertisements or similar, just provided as-is for a more holistic view on the subject. So there are certificate lifecycle services and products available for example by Venafi, Keyfactor, and AppViewX as far as I’ve seen, just to mention it.