Compartilhar via

TLS, Connectors, and You

  • Artigo

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

Comments

  • Anonymous
    January 01, 2003
    Hi Peter, you are correct. There has been talk about allowing customers to upload their domain certificates to EOP and allow EOP to present them, but at this time that is not possible. EOP will always present our own certs which have a CN of mail.protection.outlook.com.
  • Anonymous
    January 01, 2003
    Hi Thomas. It sounds like this error is thrown when your partner emails you, and because you are behind EOP your partner establishes the TLS connection with EOP. Is that flow correct?

    I'm looking at a network trace right now that was taken when a third party emails someone protected by EOP (the trace was taken on the partners server). Our EOP server will respond with its name which will be something.mail.protection.outlook.com. When TLS is established, the EOP server will present its certificate which has a CN of mail.protection.outlook.com which will match the domain of the server (banner). All your partner needs to do is validate EOP presents this cert and not your original company cert.

    If the problem is more complex than this you should open up a support ticket with our escalation engineers who can dive in to more detail.
  • Anonymous
    July 30, 2014
    The comment has been removed
  • Anonymous
    August 20, 2014
    so, the instruction is that anyone doing TLS verification must accept a mismatch between email domain name and MX domain for every EOP customer we'd like to correspond with? Really?

    The onus ought to be on EOP to present valid certificates for the domains it is hosting. Yes, that will be a lot of work for the EOP team.

    It is, however, work EOP is contracted to do and paid to perform, since they are paid to "be" their clients as far as email is concerned.
  • Anonymous
    December 24, 2014
    I only began this blog in June of this year and so it’s hard to believe that it is already six
  • Anonymous
    January 12, 2015
    What is TLS Cipher suits supported by EOP servers ?
  • Anonymous
    April 17, 2015
    Cipher strength in use : AES256-SHA or AES128.
  • Anonymous
    April 17, 2015
    http://social.technet.microsoft.com/wiki/contents/articles/1301.forcing-specific-cipher-suites-to-fope.aspx