Mar 31 2020 04:35 AM
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:"
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
Mar 31 2020 05:09 AM
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
Mar 31 2020 11:35 PM
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.
Apr 01 2020 12:03 AM
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
Apr 01 2020 12:07 AM
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
Apr 08 2020 01:37 PM
Apr 13 2020 11:51 PM - edited Apr 13 2020 11:52 PM
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
Jun 14 2020 02:48 PM
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.
Jun 15 2020 12:06 AM
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.
Jun 15 2020 02:44 AM
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?
Jun 15 2020 03:04 AM
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
Jun 15 2020 03:20 PM
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.