TLS, Connectors, and You

Update (September 3, 2014)

I was recently involved in a case where a customer needed more information about the certificate that EOP presents. Being the nice guy that I am, I wanted to share it here!

As mentioned in this article, the CN of the certificate that EOP presents is mail.protection.outlook.com. The certificate also contains the following Subject Alternative Names (SAN).

  • *.mail.eo.outlook.com
  • *.mail.protection.outlook.com
  • mail.protection.outlook.com
  • outlook.com
  • mail.messaging.microsoft.com

Of course, these can also be seen in a network trace.

Finally, this is the certificate path.

The Baltimore CyberTrust Root certificate can be downloaded from https://cacert.omniroot.com/bc2025.crt.

Note As a best practice, we recommend that you don't hard-code trusted root lists for certificate validation. Instead, you should use policy-based root certificate validation that can be updated as industry standards or certificate authorities change.

 

Original Article

Hello readers!

In this post I will be covering TLS and certificates and how they apply to EOP. Usually when organizations force TLS on mail to and from a partner they will not restrict the connection based on the certificate that the recipient server presents. Instead, they will ensure either the connecting IP or domain is correct, but after that the presented certificate isn’t restricted, or if it is the check is only to ensure it has been issued by a trusted CA and has not expired. Now, what if you have a security policy that requires checking the certificate that the partner server presents? With EOP in the middle, this certificate changes and if your partners are expecting to see your certificate when they send or receive mail from you they will need to update their configurations. Let’s take a look at this with an example.

In this example, Contoso wants to send an email message to Fabrikam. Contoso will verify that the certificate name presented by Fabrikam is mail.fabrikam.com. If the certificate is not correct, Contoso will drop the connection and will not send the message. Here's a visual.

When this connection is established, Contoso sends its certificate, mail.contoso.com to Fabrikam, and Fabrikam sends its certificate, mail.fabrikam.com, to Contoso. Contoso validates that the certificate presented by Fabrikam is mail.fabrikam.com and if instead a different certificate is presented, Contoso will drop the connection.

Now, let’s see what happens when Fabrikam implements Exchange Online Protection.

Now, the MX record for Fabrikam is pointing to EOP, so when Contoso wants to send an email to Fabrikam, Contoso will be communicating with the EOP servers. When the connection is established Contoso will present its own certificate, mail.contoso.com, but since Contoso is communicating with EOP, EOP will present its certificate which is mail.protection.outlook.com. If Contoso has restricted TLS communications to Fabrikam to only take place if the presented certificate is mail.fabrikam.com, Contoso will drop the connection and not send mail because the presented certificate was not mail.fabrikam.com. Contoso will need to update their configuration to accept the certificate mail.protection.outlook.com when sending mail to Fabrikam.

To increase the geek factor of this post, if you’re a curious individual like me, you won’t want to take someones word (even Andrew’s) that the certificate presented by EOP is mail.protection.outlook.com. You instead want to see it with your own eyes…. or maybe that’s just me. In any case, this can easily be seen by capturing network traffic that flows between your on-prem servers and EOP. Here, I have captured a network trace using Wireshark of traffic between my on-premises Exchange server and EOP. Here I can see the certificate in the flesh that is presented by EOP.

Keep in mind that the EOP certificate name is only needed if you or your partner have TLS setup to require a specific certificate name to be presented. If instead you have TLS setup to look for a certificate issued by a trusted CA or even any certificate, then the EOP certificate name will not be of interest to you.

One thing I’ll note because I’ve received a lot of questions about it. You are currently not able to import your on-premises certificate to EOP and in turn have EOP present that certificate to partners instead of mail.protection.outlook.com.

I find that most of the clients I deal with do not actually look at the presented certificate when TLS is established, however, some clients do and this article is meant for them.

Cheers!

Andrew