0

Beating my head against the wall on this one.

Used the Hybrid Configuration Wizard to setup a 2010-O365 hybrid setup today, but have had mail pending for hours now trying to figure out what the hold up is.

Error for all of them are:

Reason: [{LED=450 4.7.320 Certificate validation failed [Message=SubjectMismatch] [LastAttemptedServerName=mail.<companyname>.com] [LastAttemptedIP=40.97.231.242:25] [BN3NAM04FT016.eop-NAM04.prod.protection.outlook.com]};{MSG=SubjectMismatch};{FQDN=mail.<companyname>.com};{IP=40.97.231.242};{LRT=1/27/2019 6:51:39 AM}]. OutboundProxyTargetIP: 40.97.231.242. OutboundProxyTargetHostName: mail.<companyname>.com

I have:

  • Enable-ExchangeCertificate -thumbprint <hash> -services:SMTP on the Exchange server, then restarted the transport hub (No use of get-receiveconnector due to Exchange 2010's version of this cmdlet not having a property called -TlsCertificateName; Only 2013+)
  • Tried turning off "Always use Transport Layer Security (TLS) to secure the connection (recommended)" (and the corresponding setting on the receive connector on the Exchange 2010 side)
  • Tried "Any digital certificate, including self-signed certificates" instead of "Issued by a trusted certificate authority (CA): mail.< companyname >.com"" (and the corresponding setting on the receive connector on the Exchange 2010 side)
  • Tried turning on "Enable Domain Security (mutual auth tls)"

What is and is not working in terms of mail flow is:

Mail to O365 mailbox from external - Working
Mail from O365 mailbox to external - Working
Mail to on-prem mailbox from O365 mailbox - NOT
Mail from on-prem mailbox to O365 mailbox - Working
Mail to on-prem mailbox from external - NOT
Mail from on-prem mailbox to extenal - Working

There is a GoDaddy cert that expires in 7 months for *.< companyname >.com and a Federation cert showing under Server Config in Exchange Management Console

I have run out of possible solutions via Google, so am hoping that someone in this community can help me get inbound mail flowing again today.

Improve this question
7
  • It looks like your issue is with your onPrem Receive Connector(s) since you cannot receive to the onPrem mailbox from either 0365 or external. I'm guessing that you have the DNS MX record pointed to protection.outlook (or your O365 inbound), and that O365 has a connector to send to your onPrem. Check the TLS settings on the O365 -> onPrem send connector in the cloud, and the matching receive connector in Ex2010. Cert subject name (in the cloud) is a common issue here, and network restrictions (in Ex2010 or local firewall) are the other half of that.
    – Ruscal
    Jan 28, 2019 at 16:53
  • Thanks @Ruscal - Found the issue and answered my own question, but sure would have been helpful to have logs in O365 that said something like "mail.<companyname>.com doesn't match *.<companyname>.com in cert presented by on-prem exchange. Please let me know if you are aware of how to find this level of general logging in O365 for use next time I strike non-obvious issues.
    – user66001
    Jan 28, 2019 at 17:06
  • No joking here, but the included tech support from MS. If you'd clicked the "Support" > "New Service Request" buttons you probably would have had this squared away in the 4-6 hour range (unless you pay for higher speed support). Once you get someone on the case, they actually have good techs. Also, the error message you have explicitly said that was the issue {MSG=SubjectMismatch};{FQDN=mail.<companyname>.com}
    – Ruscal
    Jan 28, 2019 at 17:09
  • I did use the support option. 6 e-mails so far, over 3 days (when I provided the error message just like here) and they haven't figured it out. This has been my experience in past occasions, actually I have never had good support from MS (They screwed up a Vista failed upgrade back in the day, being the last time I trusted them with anything more than very basic stuff). The error message is slightly less explicit than my suggested message, and thought it was a decent assumption that *.<company name>.com would match mail.<company name>.com . If not,what is the point in having a wildcard at all?
    – user66001
    Jan 28, 2019 at 21:39
  • Sorry to hear you've had issue with their support. I guess I've just always gotten real lucky. The purpose of a wildcard is to match on may domain names that you don't necessarily know at the time of issuance (I know you know, just for anyone else); better for not-exchange-things. They work great at what they're supposed to do. But, as your answer below points out, you have the added security feature of "only trust this one explicitly listed certificate subject" turned on, but the setting entered didn't match the cert subject. Easy miss, but from a security side, it worked 100% correctly
    – Ruscal
    Jan 28, 2019 at 21:57

2 Answers 2

Reset to default
2

I certainly hope this helps someone else having the same issue to not have to spend such a long time fixing this silly one!

When one uses the O365 Hybrid configuration wizard AND has a wildcard 3rd party cert intending to be used for that O365 - on-prem exchange communication, make darned sure to put the subject of the cert in (including the wildcard, which it seems is treated literally, and not as a wildcard, when matching the cert subject presented by the on-prem server).

Putting the exact subject of the cert in the step of the hybrid configuration wizard pictured in 1, seems to put that setting in the last text box in picture 2 (which is reached by logging into O365 Exchange admin -> mail flow -> connectors -> Pick connector -> Next through to this screen.

Picture 1: Hybrid Config tool TLS config

Picture 2: O365 Connector TLS config

Improve this answer
0

You could try to resolve 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

Then bounce (restart) the transport service and the issue remediated.

Improve this answer
1
  • Hi @Jayce Yang - Found that solution on google prior to posting (think with the last line being verbatim the same). Alas 2010's associated Powershell cmdlet set-receiveconnector doesn't have a property called -TlsCertificateName associated with it (The reason I mentioned the thing I first tried above).
    – user66001
    Jan 28, 2019 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.