Need Advice: Exchange Hybrid - O365 Outbound Connector Validation

Question

Need Advice: Exchange Hybrid - O365 Outbound Connector Validation

Yang Yu 126

After running HCW (Full Classic Hybrid + Centralized Mail Transport), the outbound communication between EXO to Exchange Server 2013 didn't work. Found the validation failed if we specified subject name (the wildcard certificate *.ourdomain.com) under "Always use TLS to secure the connection".

If we changed it to "Any digital Certificate", validation passed and mail started flowing.

The validation error is "450.4.4.317 cannot connect to remote server [Message=SubjectMismatch]"

Has verified the same wildcard cert is bind to Default Frontend Receive Connector too and installed on Exchange 2013 (single server farm) too. Fortigate firewall forwards the traffic on port 25 directly to Exchange Server.

Also it is really odd not much relevant information has been logged in the receive connector log.

Any advice will be highly appreciated.

2 answers

Your answer

Answer 1

KyleXu-MSFT 26,396

@

I keep the default configuration, it could send email successfully:

So, this issue is related with the configuration on your Exchange on-premises receive connector, please have a check about it(It is a wildcard certificate from a public CA):

If all the above configurations are correct, I would suggest you try to disable firewall temporarily to check whether is this issue related with your firewall. If you cannot disable firewall temporarily, please make sure the all those IP address in the white list on your firewall.

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Yang Yu 126 Reputation points

2021-08-02T05:39:14.923+00:00

Hi Kyle,

Thanks for your response.

I double checked that our receive connector has the wildcard certificate information/configurations showing similar to your screenshot.

We cannot disable the firewall temporarily.

We have firewall rule (fortigate firewall) to allow smtp traffic from EOP IP range forwarded straight without any inspection and we could see the traffic coming through the firewall from IP in that range and forwarded to Exchange Server.

And there is nothing related logged actually in the default frontend smtp receive log too.

Could you please advise anything else I should check? Thanks again.

Answer 2

Yang Yu 126

Hi Kyle,

Thanks for your response.

I double checked that our receive connector has the wildcard certificate information/configurations showing similar to your screenshot.

We cannot disable the firewall temporarily.

We have firewall rule (fortigate firewall) to allow smtp traffic from EOP IP range forwarded straight without any inspection and we could see the traffic coming through the firewall from IP in that range and forwarded to Exchange Server.

And there is nothing related logged actually in the default frontend smtp receive log too.

Could you please advise anything else I should check? Thanks again.

KyleXu-MSFT 26,396 Reputation points

2021-08-02T09:28:58.323+00:00

I think this issue more related with the firewall, because Microsoft suggest "Don't place any servers, services, or devices between your on-premises Exchange servers and Microsoft 365 or Office 365 that process or modify SMTP traffic.":
Yang Yu 126 Reputation points

2021-08-02T09:45:36.427+00:00

Hi Kyle,

Thanks again for your response.

It is bit tricky for this as I believe having Firewall in between EXCH and EXO is quite common, instead of exposing EXCH server directly to external. Also mail flow works fine for us at this moment. The only downside is we have to choose the any digital certificate option during the validation, which is not ideal.

We had another test to use another smart host, which has the same firewall rule. The only difference is that behind that firewall is MailMarshal email security. Interesting that validation with specific wildcard certificate worked this time. So we think the firewall rule doesn't interfering with validation traffic at all.

Do you think anywhere else we should check on Exchange server side? Many thanks.
KyleXu-MSFT 26,396 Reputation points

2021-08-03T10:04:29.447+00:00

In my lab, it could works successfully, so, it means there doesn't exist with the connector configuration. The only difference between our lab is the firewall. Try to assign SMTP service to your certificate again.

I also want to confirm with you that do you do any modify to your receive connector before? My Default Frontend connector is run with the default configuration.
Yang Yu 126 Reputation points

2021-08-03T10:13:13.727+00:00

Hi Kyle,

Thanks for your response.

We do have SMTP service enabled in the certificate. You mean disable and re-enable again?

We haven’t change any setting on default front entry connector.
KyleXu-MSFT 26,396 Reputation points

2021-08-06T09:12:56.377+00:00

You can try to run assign SMTP service. If it doesn't working, you may need to use the "Any digital Certificate" configuration for your organization.
Yang Yu 126 Reputation points

2021-08-06T09:21:18.153+00:00

We are using Any Digital Certificate as the workaround at this moment. Do you see any potential security risk to use this option?

Thanks again.
KyleXu-MSFT 26,396 Reputation points

2021-08-06T09:36:47.303+00:00

So far, I have not seen related issues, if there are, I will update there.
Yang Yu 126 Reputation points

2021-08-09T23:04:51.44+00:00

Hi Kyle,

Found something may be interesting. When I ran the TLS check (online tool), I found the TLS certificate response by our Exchange Server is one of the self-signed certificates!

It is interesting that Exchange Server or should say the default front end receive connector not response my TLS check with the wildcard certificate bind to it. But it did explain why the validation error shows "subject mismatch".

Even I changed the FQDN name for our default frontend receive connector to match the smart host named used by Exchange Online send connector. It still got response with that self-signed certificate.

Any advice on why Exchange Server response with the self-signed certificate instead of wildcard certificate? Many thanks.
KyleXu-MSFT 26,396 Reputation points

2021-08-12T09:30:52.773+00:00

You can try to assign SMTP service to your self-signed certificate. Then assign it back to your wildcard certificate.
Yang Yu 126 Reputation points

2021-08-12T10:04:12.557+00:00

So you mean only enable SMTP service on one of the certificates (i.e. disable it on self-signed one and only enable on wildcard)?

The self-signed certificate has the SMTP service enabled by default and I believe the certificate was generated when the Exchange 2013 server deployed initially.

Thanks again for your help. :)
KyleXu-MSFT 26,396 Reputation points

2021-08-12T10:13:43.803+00:00

Yes, you could delete that self-signed directly. If you need it later, you could recreate it with this article.

Share via

Need Advice: Exchange Hybrid - O365 Outbound Connector Validation

2 answers

Your answer