Exchange 2010 Hybrid cannot establish Mutual TLS wrong certificate is used

When configuring an Exchange 2010 hybrid environment a Receive Connector is created on the Exchange 2010 server. This Receive Connector is configured with the FQDN entered in the Hybrid Configuration Wizard (see previous blog post on Exchange 2010 Hybrid) and the source IP addresses of the Microsoft Exchange Online servers. If one of these servers access the Exchange 2010 environment, they end up on the Office 365 Receive Connector (based on the IP address) and the correct SSL certificate is returned. This way mutual TLS is established between Exchange 2010 on-premises and Exchange Online.

It sometimes happens that the wrong certificate is used for SMTP communication between Exchange on-premises and Exchange Online, thus resulting in SMTP mail flow failure between the two.

You can check this in the Exchange Admin Center (EAC) in Exchange Online. Logon to the EAC in Exchange Online, select Mail Flow and click the Connectors tab. You’ll see two connectors. One connector for mail from Exchange 2010 to Exchange Online, and one connector for mail from Exchange Online to Exchange 2010.


You can (or have to) validate the Send Connector. When you click on validate in the EAC you have to enter an email address of a user in Exchange 2010 can click Validate. After some time the EAC will return its findings, and in this case the status is failed:


When you click on details (the pencil icon) you can see what went wrong. Clearly visible is the failure of the TLS authentication:


On the Exchange 2010 server (multi-role) there are three certificates. One certificate is the self-signed certificate (CN=SRV01), another one is a Digicert certificate ( The self-signed certificate is used for authentication with an Exchange 2010 Edge Transport server, the Digicert certificate is used for IIS and SMTP.


Based on the FQDN and the source IP address (of Exchange Online) this certificate should be returned, but obviously it returning the self-signed certificate instead of the Digicert certificate.


When checking the SMTP protocol log file of the Receive Connector (enable verbose logging) you can see that the source IP address is not the IP address of an Exchange Online server, but in this case it’s the IP address of the F5 load balancer:


This is caused the SNAT (Source Network Address Translation) in the F5 load balancer. You can easily forget this step since normal SMTP mail flow is working through the F5, and also OWA through the F5 is working fine. But for Office 365 where the original source IP address is used this becomes an issue.

After reconfiguring the F5 so that SNAT is no longer used (on inbound traffic) we can try it again. Validation of the Send Connector in EAC is now succeeding:


And also the SMTP protocol log file shows the source IP address of the Exchange Online server instead of the IP address of the F5:


Exchange 2010 hybrid is now working as expected and mutual TLS is used for securing transport between Exchange Online and Exchange 2010.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s