Generating a wildcard certificate for direct routing used in an SBC

Question

Greetings community,

I have successfully set up an SBC to manage incoming and outgoing calls with Microsoft Teams using a single domain certificate. SIP options are functional, and calls proceed smoothly.

However, I'm facing a challenge when attempting to extend this setup to support multiple domains. While I've successfully generated a certificate with multiple domains, the goal is to streamline the process by using a wildcard certificate. I obtained a wildcard certificate from a trusted source (SSL.com), which Microsoft Teams accepts.

I've ensured that the certificate includes the necessary extensions, such as Server Authentication and Client Authentication. To implement this, I followed the requirements outlined in Microsoft's official documentation available here.

Despite these efforts, using the wildcard certificate seems to disrupt the SIP options, leading to failed calls. For instance, a certificate generated for "test.abc.net" functions perfectly. Still, a certificate with the following details does not work:

Common Name (CN): *.abc.net

Subject Alternative Names (SANs): *.abc.net, abc.net

I've also taken care to import the Baltimore CyberTrust Root and DigiCert Global Root G2 root CAs.

I'm reaching out to seek advice or insights from anyone who might have encountered a similar issue or has recommendations on resolving this wildcard certificate challenge.

Thank you in advance for your assistance!

Answer 1

Hi @Samuel Beaulieu

When you set up Direct Routing, you might experience the following Session Border Controller (SBC) connectivity issues:

• Session Initiation Protocol (SIP) options are not received.
• Transport Layer Security (TLS) connections problems occur.
• The SBC doesn't respond.
• The SBC is marked as inactive in the Microsoft Teams admin center.

Such issues are most likely caused by either or both of the following conditions:

• A TLS certificate experiences problems.
• An SBC is not configured correctly for Direct Routing.

Please refer to this document lists some common issues that are related to SIP options and TLS certificates, and provides resolutions that you can try.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

---

Answer 2

Hi,

First, thank you for taking the time to answer. I have looked into the link and have verified the information with my configuration, both on Teams and on my SBC. Although, the problem still persists. I am fairly certain the problem is with TLS, as I can make the setup work with the same configuration but with a different SSL certificate with a single single domain in CN as opposed to a wildcard CN.

As such, I have more specifically looked into the TLS connection issues. The version of TLS I am using is 1.2+, so this should not be an issue. As mentioned in this post above, the CA I chose is SSL.com, which is a trusted source according to Microsoft's official documentation. I have also performed test requests to my SBC with the same certificate, meaning between my computer and the SBC, and everything works. Using SSL.com's installation checking tools, I can verify and confirm that the certificate is properly installed on the SBC and is valid.

Yet, SIP options going to either sip:sip.pstnhub.microsoft.com, sip:sip2.pstnhub.microsoft.com or sip:sip3.pstnhub.microsoft.com are not answered to with a 200 OK from Microsoft. I can confirm my SIP options requests are properly formed, the contact header does in fact contain the correct FQDN, which is also properly configured on the Microsoft account. When using the single domain certificate, the SBC does become active on Teams admin center, but not with the wildcard certificate.

Again, thanks for any future help!