ACMEv2 support for certificates on AudioCodes SBCs
- Maxime Hiez
- Audiocodes
- 28 Aug, 2026
Introduction
Renewing the TLS certificate of an SBC is a manual operation everyone knows : generate the request, get it signed, import the certificate in the right TLS Context, restart the service. Once a year, the operation goes through, but it will become untenable when the validity period of public certificates drops to 46 days, against 199 days today.
Audiocodes introduces support for the ACMEv2 protocol in version 7.60A.300.042, released on August 18, 2026 in the Latest Release branch. The SBC becomes an ACME client and handles the lifecycle of its certificates itself.
What the SBC handles
The ACME protocol automates all the exchanges with the certificate authority. The SBC now covers the following steps :
- Registration : Creation of the account with the certificate authority
- Domain validation : Proof of ownership of the requested domain
- CSR generation and submission : Building the signing request and sending it to the authority
- Certificate installation : Deployment of the signed certificate in the associated TLS Context
- Automatic renewal : Renewal triggered before expiration, without intervention
Each ACME configuration is attached to a TLS Context, which allows the certificate exposed towards Microsoft Teams and the one presented to the SIP carrier to be handled differently. The supported authorities include Let’s Encrypt and ZeroSSL.
The limits of this first version
Two constraints are worth knowing before planning a deployment.
DNS validation
Microsoft Azure DNS is the only DNS platform officially validated for DNS-01 validation in this version. Other providers may be added in the next releases, but a zone hosted elsewhere isn’t covered today.
Supported platforms
The feature is available on the Mediant 800B, Mediant 800C, Mediant VE and Mediant CE. The other models of the range don’t benefit from it in this version.
warning
LR or LTS, the choice to make
Audiocodes maintains two branches in parallel, and this announcement illustrates the difference well :
- Latest Release : New features every 4 months, recommended only if a recent feature is necessary
- Long-Term Support : Bug fixes and security fixes only, new branch every 12 to 15 months, updates roughly every two months
Concretely, an organization running its SBCs on the LTS 7.40A.600 branch can’t get ACMEv2 without changing branch. The question to settle is therefore not only technical, it is about the update policy applied to telephony.
Why this is becoming urgent
The progressive reduction of the lifetime of public certificates changes the nature of the problem. At 46 days of validity, a certificate has to be renewed about eight times a year. On a fleet of several SBCs, each with several TLS Contexts, manual renewal stops being an annual task and becomes a permanent process, with the risk of expiration that comes with it.
An expired certificate on an SBC doesn’t degrade the service, it interrupts it. Direct Routing refuses the TLS connection and all the calls stop. This is the reason why automating the renewal deserves to be handled before the constraint becomes effective.
Conclusion
ACMEv2 support answers an evolution that will apply to everyone, the reduction of the validity period of certificates. The restriction to the Latest Release branch and to Azure DNS limits the deployment scenarios for now, but the direction is clear. For the organizations whose DNS zones are already on Azure and that accept the LR branch, the feature is usable right now. For the others, this is a topic to put on the plan of the next LTS switch.
Sources
Audiocodes - Product Notice SBC/Gateway 7.60A.300
Audiocodes - Latest Release 7.6 release notes
Did you enjoy this post ? If you have any questions, comments or suggestions, please feel free to send me a message from the contact form.
Don’t forget to follow us and share this post.
