Certificate Requirements Teams Direct Routing SBC

Running Microsoft Teams with Direct Routing for Cloud Voice, you have to deploy a certificate on your SBC. This certificate is used for encryption with TLS. Often there is the question how the certificate must be configured.



SBC Public Certificate Requirements




All deployed SBCs must have a public certificate from a trusted/supported Public CA, there are 3 options to create a certificate.

Security Note:
When generating the CSR, the private key size should be at least 2048.


Support Note:
onmicrosoft.com domain for certificates is not support.



Option 1 - Single SBC

A certificate with a single SBC FQDN.
The SBC FQDN must be in the subject, common name and the Subject Alternate name.



SN/CN
SAN
{Public FQDN of SBC }
 {Public FQDN of SBC }
 


Option 2 - Multiple SBC

A certificate with a multiple SBC FQDN’s.
The SBC FQDN must be in the subject, common name and the Subject Alternate name, which includes the additional SBCs too.



SN/CN
SAN
{Public FQDN of SBC }
{Public FQDN of SBC },
{Public FQDN of Additional SBC },
{Public FQDN of Additional SBC }
 


Option 3 – Single/ Multiple SBCs with wildcard

A Wildcard certificate with a any FQDN in the common name and Subject Alternative Name (SAN), including the wildcard and SBC FQDN


SN/CN
SAN
{Public FQDN of SBC }
{ wildcard },
{Public FQDN of SBC }




Note: If you have an wildcard certificate with wildcard in the CN/SN and or only a wildcard in the SAN it will work, but it is NOT supported.


Supported Public CA


Microsoft currently supports the following Public CA’s only.  Signing a certificate therefore, is only valide by the following external Trusted root CA's


  • AffirmTrust
  • AddTrust External CA Root
  • Baltimore CyberTrust Root
  • Buypass
  • Cybertrust
  • Class 3 Public Primary Certification Authority
  • Deutsche Telekom
  • DigiCert Global Root CA
  • Entrust
  • GlobalSign
  • Go Daddy
  • GeoTrust
  • Verisign, Inc.
  • Starfield
  • Symantec Enterprise Mobile Root for Microsoft
  • SwissSign
  • Thawte Timestamping CA
  • Trustwave
  • TeliaSonera
  • T-Systems International GmbH (Deutsche Telekom)
  • QuoVadis

Comments

  1. Can you clarify option3? Particularly the NOTE. You said..."If you have an wildcard certificate with wildcard in the CN/SN and or only a wildcard in the SAN it will work, but it is NOT supported."

    I'm confused by this because MS states they support RFC2818 and provide a link to section 3.1 on their documentation. https://tools.ietf.org/html/rfc2818#section-3.1

    The RFC states *.sub1.mydomain.com as a CN/SN would work just fine. Are you suggesting to create a CSR with sbc.sub1.mydomain.com and include a dnsName in the SAN for *.sub1.mydomain.com?

    Can you show me where you got the the information to substantiate your "supportability" comment?

    Thanks!

    ReplyDelete

Post a Comment

Popular posts from this blog

How to hide users from GAL if they are AD Connect synchronized

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

MFA with Guest Access and different tenants settings