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.
- Verifique se o certificado Let's Encrypt foi criado e os serviços ativados
Get-ExchangeCertificate | Format-List FriendlyName,Thumbprint,Issuer,Subject,CertificateDomains,Services
- 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
- 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
- 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.com
seja 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ífica192.168.1.4
nã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 paramail.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.5
e aponte a resolução de nome interno paramail.contoso.com
esse endereço IP. (Não alteremail.lan.contoso.com
o que ainda aponta para o próprio servidor) 192.168.1.5
No lado do servidor ( exchange), configure os serviços de correio para escutar neste IP específico192.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.