New ExoConnectorCheck vs. documentation - Health Checker

[Niehweune]

Provide Version Number 24.02.15.1640

Describe the issue The New ExoConnectionCheck reports an issue if a send connector is present that routes mail to Exchange Online when there is no TLS certificate explicitly configured on the connector. The documentation link referred does not mention explicitly setting the TLS certificate (at least not on the send connector), nor does the PowerShell command include the TlsCertificateName parameter.

Expected behavior If it is now required to explicitly specify a TlsCertificateName on the send connector, documentation should be updated accordingly. If not, this should not be reported as an issue (but additional checks may be required to verify correct configuration).

Script Output EXO Connector Present: True Send Connector - <connectorname>: Misconfigured to send authenticated internal mail to M365. CloudServicesMailEnabled: True TLSCertificateName set: False More Information: https://aka.ms/HC-ExoConnectorIssue

Additional context Exchange automatically selects a suitable certificate that matches the FQDN on the send connector, as long as it is valid and enabled for SMTP. So the check might instead (or additionally) involve verifying if such a certificate is present, and if it is issued by a public authority (e.g. not self-signed and not issued by a AD CA).

[richfaj]

Certificate with an accepted domain has been a requirement for sending mail to/from unaccepted domain for a while now. However, explicitly setting a certificate on the send connector is not a requirement. In the scenario where there is no explicit certificate specified on the connector, the best matching certificate is selected based on the FQDN set on the connector.

To ensure the expected certificate is always selected, it is best practice to specify a TlsCertificateName. This is the same way the Hybrid Configuration Wizard does it.

Both configurations below are valid, where explicit being preferred:

// Implicit New-SendConnector -Name <DescriptiveName> -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn <CertificateHostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain>-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

// Explicit New-SendConnector -Name <DescriptiveName> -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn <HostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain>-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation -TlsCertificateName <X509CertificateName>

Perhaps warn only when the FDQN is not set?

[worldsdream]

Any update on this?

As the documentation shows:

New-SendConnector -Name "My company to Office 365" -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn mail.contoso.com -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts contoso-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

The script shows the warning:

EXO Connector Present: True Send Connector - : Misconfigured to send authenticated internal mail to M365. CloudServicesMailEnabled: True TLSCertificateName set: False More Information: https://aka.ms/HC-ExoConnectorIssue

So the documentation needs to change or the health checker script. It's not clear right now.

Thank you.

[lusassl-msft]

We will investigate this. This is caused by the change made via PR #1984 .

[arindamthokder]

Perhaps warn only when the FDQN is not set?

But in Hybrid when HCW is run, the connector FQDN is usually blank. Only TLSCertificateName is set. IMO, we should check (TLSCertificateName is set) or (fqdn parameter is set).