Comodo - Sectigo Certificate for MS Teams Direct Routing

[jers53]

Hi,

We are planning to set up Direct Routing.

For communicaiton between the SBC and MS Teams, a certificate is required and the docs state that "The certificate needs to be generated by one of the following root certificate authorities:"

https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#public-trusted-certificate-for-t...

This list also mentions "Comodo Secure Root CA".

Comodo was bought by Sectigo.

We have a certificate from Sectigo.

So I believe it meets the requirements...but I'm not sure MS Teams will accept this license.

I can't find any information about this.

At Sectigo they told me "it should be OK"

In December 2019 an anonymous user on some other website asked the same question but it was not answered so I didn't help me any further.

Does anyone have an idea how I can check/verify this in advance before starting the installation?

Kind regards,

Jeroen

[#2]

Hi @jers53 

Although I have not used the vendor for Certificate. It should be good to use the certificate from the Vendor. In case you want to have a written confirmation from MS Standpoint I would recommend that you open a Ticket with MS Team and have a confirmation from the Team on Email for documentation purpose.

With Regards.

Satish U

[#3]

Hello@RealTime_M365 

Thanks for your quick and clear reply!
I'll try contacting MS as well for an "official" confirmation, and will update this question if I get an answer

Kind regards,

Jeroen.

[#4]

Hello@RealTime_M365 

Just got off the phone with someone from MS.

They told me that even  though the company Comodo is now owned by Sectigo, it doesn't matter. The issuer of the certificate, in the contents of the certificate, needs to be "Comodo" (or another issuer that is on the list) ) and not "Sectigo".

So according to this info I'll have to request a new certificate.

Kind regards,

Jeroen

[#5]

Hi @jers53 

Thank You for the confirmation!!!

Basically Microsoft has allowed only specific vendors to be trusted with Office 365. Hence we have to have specific vendor to have the TLS Negotiation done properly. 

Do let me know in case you need any additional assistance.

With Regards,

Satish U

[#6]

There are sip trunk providers who offer a fully managed service. They will host the SBC and provide the SIP trunks; therefore they will be responsible the SBC/SIP trunk configuration and management/monitoring of the SBC. I think is worth considering and then you don't need to worry about this...

[#7]

Hi@andrewinfinitel  ,

For our solution we need to have the SBC on our own systems and need to be able to reuse the setup for different kinds of providers. So it's not an option to use a provider who delivers a part of the infrastructure.

But thanks for your input!

Kind regards,

Jeroen

[#8]

@jers53 

I was using Comodo in 2019 for my 1st SBC and it worked until,  I tried it for 2nd SBC. Took me days to figure out that Phone Systsem didnt  respon to this cert anymore. I changed to other recommended CA and worked great, and then also change the CA for my 1st SBC. 

[#9]

@godril @jers53 

Hi,

We indeed ended up requesting a new certificate from one of the provider on the MS list.

The TLS handshake between SBC and Teams was not OK using the existing Sectigo certificate.

(I should have updated this message earlier)

However @godril it's strange your Comodo certificate wasn't accepted the second time as I recently was involved in a second installation using a Comodo certificate. That worked.

Maybe you can't use a certificate for two connections because of "reasons".

Kind regards,

Jeroen.

[#10]

@jers53 

The cert were different since the domains were also different. I wasnt investigating it long enough at that time because of the time deliver constraint. At that time I tried 30 days trial from other CA and worked fine so I assumed its the CA. But thank you for updating this. Will try the Comodo once again since I will have the 3rd one coming in. By the way, is your working Comodo cert installation for multi tenants  (wildcad SSL), or single tenant?  

[#11]

@godril 

I was involved in but not in charge of this second project, I haven't had a decent look at the certificate and have no documentation available.
When I'm required to do an intervention again I'll ask if I can check the cert for research purposes.

Extra info 1

The Sectigo cert that failed was indeed a wildcard certificate for our whole domain. It probably wasn't the cause of the issue but when looking for support at our SBC vendor they informed me that wildcard certificates could cause issues if you, for example, don't anticipate the domain levels in advance.

I didn't get the full story but it was something like having a certificate for a server in a domain "server.domain.com" but also needing to have Teams users in the domain user@domain.com

So MS links the certificate to server.domain.com, but when the user@domain.com gets active, MS tries to find the certificate for only the domain.com and will not find it because the server is registered with "server.*" in it. (please note that's how I understood the story and this is no confirmed info.)

Anyway so I made sure I requested a certificate for the highest domain level possible within our organisation so I wouldn't run into issues like that.

Extra info 2

For our initial project where the Sectigo one failed, we ended up ordering at GoDaddy and I can confirm that one works for us.

Kind regards,

Jeroen

[#12]

@jers53 

Hmm.. I think this is might be something with the derived domain depth. I remembered couple months ago, my colleague had diffculty setting up custxx.sub.domain.tld (base domain SSL was sub.domain.tld) using GeoTrust. I lost the chat log where he mentioned the problem. In the end he applied SSL for domain.tld instead, hence the derived domain's custxx.domain.tld, and it worked. Need to read this more about this. I am sure I miss a lot of things. 

Thank you for the info.