Erro Nome do host NÃO VERIFICA - Certificados de teste TLS Exchange 2016 cu21

Erro Nome do host NÃO VERIFICA - Certificados de teste TLS Exchange 2016 cu21

Praticando com os certificados, vamos criptografarvitória-acmenormal é criado, envio e recebo correio normal, https no owa e os demais serviços

Testando comverificações, isso me dá uma mensagem de alerta:

O nome do host do certificado NÃO VERIFICA:

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

Não entendo o erro de DNS mail.lan.contoso.com. Achei que o erro fosse o DNS SPLIT, mas lendo nofórumeles comentam algo sobre o erro.

Entendo que os demais conectores não devem ser alterados em fóruns, livros e tutoriais, ninguém os altera. É por isso que é criado um novo conector para receber da internet, para o qual o FQDN pode ser alterado.

Recomendações destefórum, minhas configurações de DNS:

DNS do AD privado (lan.contoso.com)

Tipo de registro Nome DNS IP interno
A mail.lan.contoso.com 192.168.1.4
A DC01.lan.contoso.com 192.168.1.3

DNS privado (contoso.com) DIVIDIDO

Tipo de registro Nome DNS IP interno
A mail.contoso.com 192.168.1.4
A autodiscover.contoso.com 192.168.1.4

DNS público (contoso.com)

Tipo de registro Nome DNS Valor
A mail.contoso.com xxx.xxx.xxx.xxx
A autodiscover.contoso.com xxx.xxx.xxx.xxx
MX @ mail.contoso.com

Responder1

Depois de muitos testes, entendi algumas das mensagens de erro emCheckTls. É o certificado utilizado pelo conector de recepção do Exchange. eu testo novamente emCheckTlse passou em todo o teste sem erros.

Obrigado pelo conselho @Lutz Willek, continuarei praticando.


Compartilho minha solução com você, espero que ajude outras pessoas com esse problema.

Não sei se é um bom procedimento, a solução que estou usando Use o seguinteDocumentação da Microsoftpara referência.

  1. Verifique se o certificado Let's Encrypt foi criado e os serviços ativados
    Get-ExchangeCertificate | Format-List FriendlyName,Thumbprint,Issuer,Subject,CertificateDomains,Services
  1. Identifique o conector de recepção para atribuir, eu estava mais focado em usuários anônimos
    Get-ReceiveConnector | where {$_.Bindings -like '*25' -AND $_.PermissionGroups -like '*AnonymousUsers*'} | Format-List Identity,Bindings,RemoteIPRanges,PermissionGroups
  1. Tendo identificado o conector, prossigo para atribuir o certificado
    $cert = Get-ExchangeCertificate -Thumbprint xxxxxxxx
    $tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"
    Set-ReceiveConnector "Server_Name\Default Frontend Server_Name" -TlsCertificateName $tlscertificatename
  1. Verifique se o certificado foi atribuído ao conector de recepção
    Get-ReceiveConnector -Identity "Server_Name\Default Frontend Server_Name" | Format-List Name,Fqdn,TlsCertificateName

Responder2

O outroresponderestá 100% correto.

O que aconteceu é que foi criado um servidor (interno), utilizando o nome do host mail.lan.contoso.com. O erro é que o certificado que foi criado para este host ainda é apresentado caso o nome DNS mail.contoso.comseja usado para conectar-se ao servidor.


Então vocêprecisarfaça o seguinte para criar um serviço funcional:

  • Remova a configuração de DNS dividido para autodiscover.contoso.com, pois uma resolução de nome específica 192.168.1.4não é necessária em sua rede interna. (Como a resolução de nome público sempre pode ser usada)
  • Configure seus clientes para se conectarem ao mail.contoso.com. (verifique as configurações de descoberta automática)
  • Configure seu servidor Exchange para usar o certificado para o qual foi criado mail.contoso.com- atualmente, o certificado para mail.lan.contoso.comé apresentado.

O que vocêpoderiafazer, para aumentar a confiabilidade e diminuir o esforço de manutenção: (Isso permite dividir o serviço do servidor)

  • No lado do servidor, configure um segundo endereço IP interno 192.168.1.5e aponte a resolução de nome interno para mail.contoso.comesse endereço IP. (Não altere mail.lan.contoso.como que ainda aponta para o próprio servidor)
  • 192.168.1.5No lado do servidor ( exchange), configure os serviços de correio para escutar neste IP específico 192.168.1.4.

O que você poderia pelo menosconsiderar, não está usandodividir DNSde forma alguma:

  • A minha experiência indica que existem desvantagens consideráveis ​​se o DNS dividido não for completamente implementado e também que a experiência de rede do administrador médio, infelizmente, não é suficiente para supervisionar e lidar com todos os desafios associados.
  • Outro motivo importante é um projeto de rede simplificado, que ajuda (entre outras vantagens) a isolar mais rapidamente uma causa raiz em caso de incidente.
  • Não há muitas vantagens reais em uma configuração de DNS dividido que não possa ser alcançada de forma mais eficiente usando outros métodos.

informação relacionada