by As announced here, Microsoft will soon be updating the root certificates that are (as their name suggests) foundational when it comes to protecting your Microsoft 365 traffic. For your day to day devices that you use to access Microsoft 365 services, this change should have no impact: your devices should already trust the new root certificate, and mechanisms will be in place that ensure trusted certificates are automatically updated.
However, there are some scenarios where trusted root certificates are manually configured, and as such will need to be updated. One such use case is Microsoft Teams Direct Routing. Session Border Controllers (SBCs) that support direct routing typically require manual management of trusted root certificates, and will need to have the new trusted root certs added before the change. One of my older blog posts outlines how certificates are managed on Ribbon SBCs.
Up until this change, the Baltimore CyberTrust Root certificate was installed on SBCs to support TLS authentication. New TLS certificates used by Microsoft 365 services will now chain up to one of the following Root CAs:
| Common Name of the CA | Thumbprint (SHA1) |
|---|---|
| DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
| Microsoft RSA Root Certificate Authority 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
| Microsoft ECC Root Certificate Authority 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
Time wise, it looks like that this change will rollout out between now and October 2022. Now is a good time to check your SBCs and make sure these have also been added to avoid any unnecessary downtime.
dmunified 
Hi, Thanks for the reminder however we got a potential issue. We imported the new root cert and tried to test it using the test server microsoft provided sip.mspki.pstnhub.microsoft.com. However we don’t get any 200 OK replies after our SBC sends hello messages. The logs show a successful TLS connection however the logs also show our SBC establishing an SSLV3/TLS1 connection even though we’ve set the TLS to 1.2. Could you advise if you know the answer to why this is?
See below logs which show a successful encrypted connection but also an encrypted connection that appears to use TLSv1 instead of TLSv1.2:
172.16.20.248:55358 [2023-08-29 07:02:57,973] 5860 0001 com.sonus.sbc.sip.libctl INFO (TransportTlsSocket.cpp:2522) – SSL_connect after: socket fd=139 for conn_id: 33912 in state: SSLv3 read finished A, negotiated version: TLSv1/SSLv3 and cipher: ECDHE-RSA-AES256-SHA384
172.16.20.248:55358 [2023-08-29 07:02:27,551] 4992 0007 com.sonus.sbc.sip.libctl INFO (TransportTlsSocket.cpp:1079) – TLS Client connected for conn_id: 33910 on handle: 0x41e96680, Local Port: 25642, Remote IP:Port(52.112.39.0:5061), fd=118, current active sockets: 8
Hi Jay, hard to say without seeing SBC config and full traces, I also haven’t tested sip.mspki.pstnhub.microsoft.com – I gather you’ve ruled out firewall interference?
Hi Damien,
Thanks for your speedy reply! Microsoft did make an announcement that today they would be a 24 hour switchover and switch-back to the new root cert and we haven’t had issues so that looks good. But nevertheless, still interested in knowing if it worked for sure. The only problem is to get the logs in the trace we would have to remove a SIP server and re-add so that the TLS can be re-negotiated but I don’t think the client wants to make any changes. Is there a way of knowing what certs are being used without making any changes? Thanks.
Have you tried enabling some of the more verbose tracing subsystem elements? I imagine you might be able to expose the root cert that’s being used to negotiate TLS on each call setup\options etc, could also try a quick disable\re-enable of the signalling group to renegotiate and see the traffic in traces.
Good luck 🙂