This article is correct at the time of publishing.
I’m happy to take critique and update any factual errors
I will link any new updates here or below!
Hi there, you’re reading this article because either;
- You’re a vendor I’m trying to help improve things for our customers
- You’re weird and read my stuff anyway (Thanks)
- You’re a consumer who uses SBC’s for Internet telephony and want to make sense of the new Certificate Lifetime Changes and what it means for you.
If you’re the latter, I’m sorry, but certain SBC vendors attitude to this isn’t great, and I’m trying to get that changed. (Unless you’re using an anynode SBC, then the solution is already baked in!)
To be clear, this is not a Microsoft Teams issue. Microsoft are already aware of the challenges outlined here and are actively engaging with me on a way forward.
What’s this all about anyway?
If you’re not aware, or you’ve been living under Patricks rock from SpongeBob Square pants. Midway through 2025, the CA/Browser Forum officially voted to reduce TLS certificate lifetime to just 47 days by 2029. This includes ALL TLS certificates issued by any of the major cert vendors and has already seen a reduction to just 200 days as of March 2026
- As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.
- As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.
- As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.
The CA/Browser Forum understood that this would have a massive impact on IT admins and the industry has clearly aligned around ACME (that thing Let’s Encrypt uses) as the only scalable renewal mechanism moving forward. Allowing for servers/appliances/etc to just update their own certs (or have software do it for them!) without Admin intervention in a secure manner.
Why are cert vendors doing this?
It’s outside the scope of this discussion, but it comes down to CRLS and other certificate invalidation methods are slow, or get cached.
Meaning once a cert is stolen, it can be used for quite some time before a browser or endpoint notices the cert has been revoked.
Having shorter certificate lifetimes with automated validation helps improve certificate security for everyone.
Why does any of this matter?
Teams‑certified SBCs use TLS certificates to authenticate and secure SIP signaling for all calls they send to Microsoft Teams (and, in some cases, online contact centre platforms). These certificates are key to establishing trust between the SBC and Microsoft/Contact Centre.
If the certificate expires or becomes invalid, the TLS handshake fails. When the TLS handshake fails, SIP signaling fails, and when signaling fails, Teams Direct Routing (your telephone connectivity) stops working!
This isn’t a soft failure either, no “Expired Certificate” warning like on a website. Calls just won’t connect, customers won’t be able to reach you, they won’t care why. Just that you don’t answer.
Okay, big deal, I’ll just automate my certificate renewal on my SBCs
*BZZZZT WRONG!*
At the time of writing this, only ONE of the Microsoft Teams certified SBC vendors fully support the ACME protocol. And that’s anynode.
Otherwise, Oracle, Cisco, AudioCodes and Ribbon/Sonus, all don’t support the protocol. When I brought this up with one of the bigger ones (I’m not naming them, yet.. pull your finger out guys), I was told to rely on their APIs to ‘replace the certificate’, with no ACME support planned.
Okay James, why’s this a problem? Just write a script with Copilot
I was going to… spent last week and my easter looking into the protocol and how I could implement it in PowerShell and pre-existing open source code. Planned the whole thing out on my drive home talking to Copilot, I even got approval from my employer Jasco Consulting to develop it on company time and release it open source because they understood everyone benefits from the community’s contributions.
But here’s the kicker, as part of the changes, the CA/Browser Forum’s new standards will only allow for Domain Control Validation (the bit where they check you own the domain by emailing you/asking for a custom DNS entry) to last 10 days! So, unless you want my script to have access to your DNS or a public IP on port 80. That’s not going to happen!
Why does the SBC need a certificate anyway?
For the non-SBC nerds in the room, SBCs are like a firewall for SIP, they are designed to be on your networks edge, only mildly protected by your firewall, with it doing basic layer 4 ACL’s. The SBC is the SIP Firewall. It’s responsible for doing the SIP inspection, encryption, connection tracking etc. So, your Firewall shouldn’t be inspecting any of it’s traffic. Meaning that your Firewall/VIP/Loadbalancers etc do not have the TLS certificate. The SBC does.
So that means the SBC itself needs to have it’s certificate replaced. Not the Firewall/LoadBalancer
As such, today the SBC vendors allow you to upload a certificate via their management interface or API, but that’s about it.
Why is it that tricky?
As part of certificate vendors renewal process, Certificate Authorities MUST be able to perform an automated check on the domain as part of their Domain Control Validation.
So, lets say we have an SBC at a customer. sbc1.contoso.com and this is up for renewal.
To do this manually, you would have to get a CSR from the SBC, upload it to the cert vendor, they would then ask you to make a DNS change to prove you own the domain, then issue the certificate, then you can install it.
If you’re quick, and have access to everything, you can do it in an hour. Now scale that to 100s of SBC’s needing a certificate each month and you can see, its just not scalable. And lets be honest, you don’t have access to everything, do you?
There are 3 ways of doing this automatically using ACME.
In each method the SBC or certificate management agent must connect with the certificate vendor and request a renewal via the ACME protocol. As part of this the vendor will provide a token which must be displayed in some form on sbc1.contoso.com (not somethingelse.contoso.com)
(Note, this is a gross simplification, some of this may be incorrect. please see RFC 8555 for more info)
DNS – Not practical for SBCs
SBC/Agent will request renewal and get token via ACME
Certificate vendors will then attempt to look for a TXT record with that token and if found, issue the certificate.
A custom tool here is impractical because each customer uses a different DNS provider, and more importantly, as UC partners we are never going to get access to a customers DNS settings. (Not to mention DNSSEC headaches)
A more generic tool that manages all the customers certificates might work, but then we are relying on that tool supporting all the SBC vendors and their different API’s and annoyingly, whatever certificate management tool the customer is using, supporting your SBC.
HTTP – Practical for SBC, not for scripts
SBC/Agent will request renewal and get token via ACME
The certificate vendor will then attempt to access http://sbc1.contoso.com/.well-known/acme-challenge/ on port 80 looking for the token.
It’s important to note here that this is the FQDN of the SBC, NOT http://something-else.contoso.com/.well-known/acme-challenge/ so, even if you did have a third party tool/script you would have to port forward port 80 of the SBC FQDN to it, and I really don’t want my PowerShell script being on the Internet by itself being a security risk.
TLS Based – Practical for SBC, not for scripts
SBC/Agent will request renewal and get token via ACME
The certificate vendor will then attempt to access https://sbc1.contoso.com/ on port 443 and check the certificate that the SBC offers looking for an ALPN protocol of “acme-tls/1” and the token
This requires control over the TLS listener directly, so will need a webserver that supports ACME, but doesn’t expose port 80. (still requires 443 though)
So what do I do?
Tell vendors this isn’t good enough. This is a problem for our industry, one that we need to solve sooner than later. There are many open source ACME agents out there that SBC vendors could implement and whilst certificate vendors have provided generic tools for Windows and Linux machines that might not support it out of the box, its unreasonable for them to write tools for appliances like Firewalls, load balancers etc, so they will need to implement this on their own. And so far in my discussions with SBC vendors. They aren’t interested.
So, raise a ticket with your SBC vendor. Send them this article. Make them earn that yearly software renewal. Or find a vendor that actually cares. I’m already in discussions with Microsoft, as if the SBC vendors wont do it, maybe we can force them to as part of certification.
Thanks.