450 4.7.320 Certificate validation failed

I wanted to share something peculiar that happened while working with a customer the other day.
We had finished a hybrid setup with Exchange 2013, and most of the users where still on-premise. The minute we switched the mail flow to go through Exchange Online Protection instead of their old setup, we started having some challenges. Even though we didn’t experience any challenges when we did the testing of the mail flow on beforehand.

Now some of the messages took forever to go through Office 365 and Exchange Online Protection, but some went through straight away.

When tracing the messages, we could see this error message on the deferred messages:

Reason: [{LED=450 4.7.320 Certificate validation failed [Message=SubjectMismatch] [LastAttemptedServerName=mail.contoso.com] [LastAttemptedIP=172.16.254.1:25] [XXXEUR01FTXXX.eop-EUR01.prod.protection.outlook.com]};{MSG=SubjectMismatch};{FQDN=mail.contoso.com};{IP=172.16.254.1};{LRT=11/1/2017 12:12:45 PM}]. OutboundProxyTargetIP: 172.16.254.1. OutboundProxyTargetHostName: mail.contoso.com

The strange thing in this case, was that some messages seemed to be OK, but the other half seemed to have a problem with the certificate.

After some time it came to me that the receiver connector on the on-premises Exchange server contained some settings for the certificate for “mail.contoso.com”, and this is something that is automatically configured by the Hybrid Configuration Wizard:

Set-ReceiveConnector -Identity 'SERVERNAME\Default Frontend SERVERNAME' -TLSCertificateName [CERTNAME] -TLSDomainCapabilities [CERTDOMAINCAP]

Then I came to the discovery; only one of the two Exchange servers with a receiver connector had been configured with the TLS Certificate settings.

By using PowerShell:

Get-ReceiveConnector -Identity 'SERVERNAME\Default Frontend SERVERNAME' |fl

I could see that the attributes TlsCertificationName and TlsDomainCapabilities where set for one of the servers, but not the other.

“Easy!” – you say,  “then we just need to run it for the other one as well? ”
Of course, the only thing to remember is to get the correct Certificate Name, and then run the Set-Receiveconnector cmdlet.

First i had to find the Thumbprint of the Certificate by running:

Get-ExchangeCertificate

Take note of the Thumbprint for the right certificate, then go on…

$certificate = Get-ExchangeCertificate -Thumbprint 0011223344556677889900112233445566778899
$tlscertificatename = "<i>$<$certificate.Issuer><s>$<$certificate.Subject>"
Set-ReceiveConnector -Identity 'SERVERNAME\Default Frontend SERVERNAME' -TLSCertificateName $tlscertificatename -TLSDomainCapabilities mail.protection.outlook.com:AcceptCloudServiceMail

Now after running this, and checking that everything is right with the Get-ReceiveConnector cmdlet, things started working as it should again.

//xostmoen – Alexander Østmoen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

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

Google photo

You are commenting using your Google 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