Score:2

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

cn flag

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)

Record Type DNS Name Internal IP
A mail.lan.contoso.com 192.168.1.4
A DC01.lan.contoso.com 192.168.1.3

Private DNS (contoso.com) SPLIT

Record Type DNS Name Internal IP
A mail.contoso.com 192.168.1.4
A autodiscover.contoso.com 192.168.1.4

Public DNS (contoso.com)

Record Type DNS Name Value
A mail.contoso.com xxx.xxx.xxx.xxx
A autodiscover.contoso.com xxx.xxx.xxx.xxx
MX @ mail.contoso.com
Ivan_Wang avatar
us flag
Here is a similar thread, please check if the answers in it are helpful: **Cert Hostname DOES NOT VERIFY, certificate let's encrypt exchange 2016 cu 21** (https://docs.microsoft.com/en-us/answers/questions/536588/cert-hostname-does-not-verify-certificate-let39s-e.html)
Score:2
cn flag

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
  1. 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
  1. 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
  1. Verify if the certificate was assigned to the reception connector
    Get-ReceiveConnector -Identity "Server_Name\Default Frontend Server_Name" | Format-List Name,Fqdn,TlsCertificateName
Ivan_Wang avatar
us flag
I'm glad that you've fixed the TLS issue, thanks for your sharing at the same time. If everything works well, you could mark your solution as the best answer so that others with the same problem will find it.
Score:1
in flag

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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.