Início / server / Perguntas / 1076710
Accepted
Luigi
Asked: 2021-09-06 16:33:59 +0800 CST

Erro Hostname NÃO VERIFICA - Testar certificados TLS Exchange 2016 cu21

  • 772

Praticando com os certificados, em vamos criptografar win-acme normal é criado, envio e recebo correio normal, https no owa e demais serviços

Testando com checktls , ele me dá uma mensagem de alerta:

Cert Hostname 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 era o DNS SPLIT, mas lendo no fórum eles 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 um novo conector é criado para receber da internet, para o qual o FQDN pode ser alterado.

Recomendações deste fórum , minhas configurações de dns:

DNS privado do AD (lan.contoso.com)

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

DNS privado (contoso.com) DIVIDIDO

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

DNS público (contoso.com)

Tipo de registro Nome DNS Valor
UMA mail.contoso.com xxx.xxx.xxx.xxx
UMA autodiscover.contoso.com xxx.xxx.xxx.xxx
MX @ mail.contoso.com
domain-name-system ssl lets-encrypt exchange-2016

2 respostas

  1. Best Answer

    Após muitos testes, entendi algumas das mensagens de erro em CheckTls . É o certificado usado pelo conector de recepção do Exchange. Eu testei novamente no CheckTls e passei no teste inteiro sem erros.

    Obrigado pela dica @Lutz Willek, vou continuar 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 a seguinte documentação da Microsoft para referência.

    1. Verifique se o certificado Let's Encrypt foi criado e os serviços habilitados
        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
    • 2

  2. A outra resposta está 100% correta.

    O que aconteceu é que um servidor (interno) foi criado, usando 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 ao servidor.

    Então você precisa fazer 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 para 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 conectar ao mail.contoso.com. (verifique as configurações de descoberta automática)
    • Configure seu servidor de troca para usar o certificado para o qual foi criado mail.contoso.com- atualmente, o certificado para mail.lan.contoso.comé apresentado.

    O que você poderia fazer 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 IP 192.168.1.5e aponte a resolução de nome interno para mail.contoso.compara esse endereço IP. (Não altere o mail.lan.contoso.comque ainda aponta para o próprio servidor)
    • No lado do servidor (exchange), configure os serviços de correio para escutar neste IP 192.168.1.5específico 192.168.1.4.

    O que você poderia pelo menos considerar é não usar DNS dividido :

    • Minha experiência indica que há desvantagens consideráveis ​​se o DNS dividido não for implementado completamente, 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 uma causa raiz mais rapidamente em caso de incidente.
    • Não há muitas vantagens reais de uma configuração de DNS dividido que não possa ser alcançada de forma mais eficiente usando outros métodos.
    • 1

relate perguntas