Partager via

Mail not routing to on-premise Exchange 2013 environment from O365 with 450 4.7.320 Certificate validation failed error

  • Article

Issue:

User is trying to send email from his O365 Tenant in to the OnPrem Exchange 2013 environment. The email fails with the following reason (as seen in the message tracking logs in O365:

Reason: [{LED=450 4.7.320 Certificate validation failed};{MSG=SubjectMismatch};{FQDN=hybrid.domain.com};{IP=###.###.###.###};{LRT=4/14/2017 1:07:17 PM}]. OutboundProxyTargetIP: ###.###.###.###. OutboundProxyTargetHostName: hybrid.domain.com

Cause:

We found that the certificate it was trying to use for TLS in the Exchange OnPrem space was not the certificate that was being presented by the O365 connector. By looking in the SmtpReceive protocol logs in Exchange 2013 onPrem, we saw the following:

2017-04-14T17:00:41.125Z,SERVER1\Default Frontend SERVER1,08D479E14521204D,20,172.20.102.10:25,155.39.36.248:30648,*,,Sending certificate
2017-04-14T17:00:41.125Z,SERVER1\Default Frontend SERVER1,08D479E14521204D,21,172.20.102.10:25,155.39.36.248:30648,*,CN=SERVER1,Certificate subject
2017-04-14T17:00:41.125Z,SERVER1\Default Frontend SERVER1,08D479E14521204D,22,172.20.102.10:25,155.39.36.248:30648,*,CN=SERVER1,Certificate issuer name
2017-04-14T17:00:41.125Z,SERVER1\Default Frontend SERVER1,08D479E14521204D,23,172.20.102.10:25,155.39.36.248:30648,*,1234567890ABCDEF1234567890ABCDEF,Certificate serial number
2017-04-14T17:00:41.125Z,SERVER1\Default Frontend SERVER1,08D479E14521204D,24,172.20.102.10:25,155.39.36.248:30648,*,9876534210FEDCBA9876534210FEDCBA123456789,Certificate thumbprint
2017-04-14T17:00:41.125Z,SERVER1\Default Frontend SERVER1,08D479E14521204D,25,172.20.102.10:25,155.39.36.248:30648,*,SERVER1;SERVER1.domain.com,Certificate alternate names

The certificate with the thumbprint of 9876534210FEDCBA9876534210FEDCBA123456789 was a self signed exchange certificate in the OnPrem environment and did not have the SAN name of Hybrid.domain.com in it. The correct certificate is a third party SAN certificate which was already installed in exchange but for whatever reason was not being used by the Default Frontend Receive Connector. For this articles sake, we will say that certificate had a thumbprint of 4C0FA622D0D66E777AA123B1AF123456F001AE23.

We did a Get-ReceiveConnector "SERVER1\Default Frontend SERVER1" | fl TlsCertificateName and saw that it was set to Null.

Resolution:

We resolved this by adding the TlsCertificateName for the Default Frontend Receive connector using the following commands:
$tlscert=Get-ExchangeCertificate 4C0FA622D0D66E777AA123B1AF123456F001AE23
$tlscertname="<I>$($TLScert.Issuer)<S>$($TLSCert.Subject)"
Get-ReceiveConnector "SERVER1\Default Frontend SERVER1" | Set-ReceiveConnector -TlsCertificateName $tlscertname
We then bounced the transport service and the issue remediated.

NOTE:

This issue can also occur in Exchange 2016. The fix is the same for both.

Comments

  • Anonymous
    March 02, 2018
    If you are seeing this issue with Exchange 2010, this fix does not apply.  On 2010, you will see this same error if you have an SNAT address between the client and Exchange. The receive connectors are triggered by the IP that is presented to Exchange. With SNAT, the SNAT address is what is presented, so you have to add that to the receive connector in order for it to use the right one and get the right certificate.
  • Anonymous
    December 14, 2018
    The comment has been removed