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.
So what to do when MAT validation by partner company is failing?
We use EOP and a partner company wants to use TLS wth us but their test throws the error:
The MTA cannot be validated if the CN subject of the certificate doesn't match the banner of the mail gateway or the rdns entry. To resolve this issue the banner of the mail gateway must be renamed to match the CN subject of the certificate or a new certificate
must be installed.
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.