Error Hostname DOES NOT VERIFY - Test certificates TLS Exchange 2016 cu21

Practicing with the certificates, in let's encrypt win-acme normal is created, I send and receive normal mail, https in owa and the other services

Testing with checktls, it gives me an alert message :

Cert Hostname DOES NOT VERIFY:

(mail.contoso.com != mail | DNS:mail | DNS:mail.lan.contoso.com)

I don't understand the mail.lan.contoso.com DNS error. I thought the error was the DNS SPLIT, but reading in the forum they comment on something about the error.

I understand that the other connectors should not be changed in forums, books and tutorials, nobody changes them. That is why a new connector is created to receive from the internet, to which the FQDN can be changed.

Recommendations of this forum, my dns settings :

Private AD DNS (lan.contoso.com)

Private DNS (contoso.com) SPLIT

Public DNS (contoso.com)

After much testing, I understand some of the error message in CheckTls. It is the certificate used by the Exchange reception connector. I retest in CheckTls and passed the entire test without errors.

Thanks for the advice @Lutz Willek , I will continue to practice.

I share my solution with you, I hope it helps others with this problem.

I do not know if it is a good procedure, the solution that I am using Use the following Microsoft documentation for reference.

1. Verify the Let's Encrypt certificate is created and services enabled

    Get-ExchangeCertificate | Format-List FriendlyName,Thumbprint,Issuer,Subject,CertificateDomains,Services

2. Identify the reception connector to assign, I was more focused on anonymous users

    Get-ReceiveConnector | where {$_.Bindings -like '*25' -AND $_.PermissionGroups -like '*AnonymousUsers*'} | Format-List Identity,Bindings,RemoteIPRanges,PermissionGroups

3. Having identified the connector, I proceed to assign the certificate

    $cert = Get-ExchangeCertificate -Thumbprint xxxxxxxx

    $tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

    Set-ReceiveConnector "Server_Name\Default Frontend Server_Name" -TlsCertificateName $tlscertificatename

4. Verify if the certificate was assigned to the reception connector

    Get-ReceiveConnector -Identity "Server_Name\Default Frontend Server_Name" | Format-List Name,Fqdn,TlsCertificateName

The other answer is 100% correct.

What happened is that a (internal) server has been created, using the host name mail.lan.contoso.com. The error is that the certificate which has created for this host is still presented in case the dns name mail.contoso.com is used to connect to the server.

So you need to do the following, in order to create a functional service:

• Remove the split DNS configuration for autodiscover.contoso.com, as a specific name resolution to 192.168.1.4 is not needed within your internal network. (As the public name resolution can be always used)
• Configure your clients to connect to mail.contoso.com. (check the autodiscover settings)
• Configure your exchange server to use the certificate which has been created for mail.contoso.com - currently, the certificate for mail.lan.contoso.com is presented.

What you could do, to increase reliability and decrease maintenance effort: (This allows to split the service from the server)

• On server side, configure a second IP internal IP address 192.168.1.5 and point the internal name resolution to for mail.contoso.com to this IP address. (Do not change mail.lan.contoso.com which still points to the server itself)
• On server (exchange) side, configure the mail services to listen on this specific IP 192.168.1.5 instead 192.168.1.4.

What you could at least consider, is not using split DNS at all:

• My experience indicates that there are considerable disadvantages if split DNS is not implemented thoroughly, and also that the average administrator's network experience is unfortunately not sufficient to oversee and to deal with all the associated challenges.
• Another important reason is a simplified network design, which helps (among other advantages) to isolate a root cause faster in case of an incident.
• There are not many real advantages of a split DNS setup that cannot be achieved more efficiently using other methods.