☰

o nome do certificado de segurança é inválido ou não corresponde ao nome do site

tag-icon • tag-icon ssl exchange-2013
o nome do certificado de segurança é inválido ou não corresponde ao nome do site

Nosso servidor Exchange está funcionando com um certificado assinado internamente há algum tempo. Hoje comprei um certificado SSL confiável (wilcard) e instalei no servidor.

O certificado é emitido para *.example.no e não oferece exceções de segurança quando acesso a interface da web a https://mail.example.no/owapartir do navegador da web.

Agora, quando abro o Outlook, recebo este erro de validação de certificado. Eu tentei todas as soluções padrão fornecidas, que envolviam principalmente definir o URL externo como o URL interno.

  • FQDN interno:mx.example.local
  • FQDN externo:mail.example.no
  • Mensagem de erro: há um problema com o certificado de segurança do servidor proxy. O nome no certificado de segurança é inválido ou não corresponde ao nome do site de destino mx.example.local. O Outlook não consegue se conectar ao servidor proxy. (Código de erro 10)

O que eu fiz:

Set-WebServicesVirtualDirectory –Identity ‘mx\EWS (Default Web Site)’ –ExternalUrl https://mail.example.no/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "mx\EWS (Default Web Site)" –InternalUrl https://mail.example.no/EWS/Exchange.asmx

Set-OABVirtualDirectory -Identity “mx\OAB (Default Web Site)” -InternalURL https://mail.example.no/OAB

Set-ActiveSyncVirtualDirectory -Identity “mx\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.example.no/Microsoft-Server-Activesync

Set-ClientAccessServer -Identity mx -AutodiscoverServiceInternalUri https://mail.example.no/autodiscover/autodiscover.xml

O resultado:

[PS] C:\>Get-WebServicesVirtualDirectory | Select InternalUrl, BasicAuthentication, ExternalUrl, Identity | Format-List

InternalUrl         : https://mail.example.no/ews/exchange.asmx
BasicAuthentication : True
ExternalUrl         : https://mail.example.no/ews/exchange.asmx
Identity            : mx\EWS (Default Web Site)

[PS] C:\>Get-OabVirtualDirectory | Select InternalUrl, ExternalUrl, Identity | Format-List

InternalUrl : https://mail.example.no/oab
ExternalUrl : https://mail.example.no/OAB
Identity    : mx\OAB (Default Web Site)

[PS] C:\>Get-ActiveSyncVirtualDirectory | Select InternalUrl, ExternalUrl, Identity | Format-List

InternalUrl : https://mail.example.no/Microsoft-Server-ActiveSync
ExternalUrl : https://mail.example.no/Microsoft-Server-ActiveSync
Identity    : mx\Microsoft-Server-ActiveSync (Default Web Site)

[PS] C:\>Get-ClientAccessServer | Select Fqdn, AutoDiscoverServiceInternalUri, Identity | Format-List

Fqdn                           : mx.example.local
AutoDiscoverServiceInternalUri : https://mail.example.no/autodiscover/autodiscover.xml
Identity                       : mx

Depois disso eu tenho

  • Reciclei o pool de aplicativos IIS MSExchangeAutoDiscoverAppPool (que não fez com que a mensagem desaparecesse, então eu ...)
  • Reiniciei todo o servidor de e-mail (isso também não fez com que a mensagem desaparecesse, então eu ...)
  • Entrei em Painel de Controle -> Correio -> Contas de Email e escolhi Reparar na minha conta (já que estou fazendo esta postagem, você deve ter adivinhado que isso também não teve efeito)
  • DNS liberado do computador cliente (caso o URL de descoberta automática tenha sido ignorado)
  • Reparei a conta de e-mail mais uma vez
  • Tentei editar a conta e colocar o FQDN público, mail.example.no, como endereço do servidor
  • EDITAR: Tentei excluir e recriar a conta. Excluiu todo o perfil de e-mail, pastas %AppData%\Local\Outlook e %AppData%\Local\Outlook. Ainda sem sucesso.

Estou ficando sem ideias agora... todos os sites que visitei na web sugerem que eu faça o que acabei de fazer e espera-se que o resultado seja igual ao meu....

ATUALIZAR: Um dos meus usuários não consegue nem fazer login no Outlook em sua estação de trabalho. A conta está OK (o e-mail no celular e no cliente web funciona), mas o Outlook continua repetindo a solicitação de senha e não sai do modo offline.

ATUALIZAR: Fiz uma verificação de SSL no site da Digicert para ver se o certificado está instalado corretamente. O servidor passou em todas as verificações, a única coisa que fui avisado foi o uso do protocolo SSL 3.0: Protocol Support TLS 1.1, TLS 1.0, SSL 3.0. SSL 3.0 é uma versão de protocolo desatualizada com vulnerabilidades conhecidas.

ATUALIZAÇÃO 150709:

Isenção de responsabilidade: nenhum endereço IP interno real foi prejudicado com esta atualização

  • Configurei uma nova zona de pesquisa direta no DNS, mail.example.nocom um registro em branco (A) apontando para 192.168.1.1, o endereço IP hipotético do servidor de e-mail
  • Na zona de pesquisa reversa para 192.168.1.in-adds.arpa, tenho um registro e (PTR) chamado 192.168.1.1 apontando para mail.example.no
  • BaixadoFerramenta de nome interno DigiCert® para Microsoft Exchange
  • Executei a ferramenta, a maioria dos endereços estava correta, mas OWAVirtualDirectory ECPVirtualDirectory ainda estava se referindo a mx.example.local, então mudei-os para mail.example.no

nslookupo resultado parece promissor:

D:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

D:\>nslookup mail.example.no
Server:  dc1.example.local
Address:  192.168.1.2

Name:    mail.example.no
Address:  192.168.1.1


D:\>nslookup 192.168.1.1
Server:  dc.example.local
Address:  192.168.1.2

Name:    mail.example.no
Address:  192.168.1.1

O Outlook não.....

Pequeno teste:

  1. Fui para Configurações da conta -> Mais configurações -> Conexão -> Configurações de proxy do Exchange.
  2. Alterou o URL de conexão parahttps://mail.example.no
  3. Alterado o nome principal permitido paramsstd:*.example.no
  4. Outlook reiniciado. O erro de certificado não aparece agora, mas percebo que não estou conectado...
  5. Configurações da conta mais uma vez, desta vez escolhi Reparo automático
  6. Outlook reiniciado
  7. Agora, se eu voltar às configurações do proxy do Exchange, a URL interna retornou...

Responder1

O certificado do emissor terceirizado precisará ter seu FQDN interno como um nome alternativo de assunto para poder trabalhar com sua descoberta automática local que os usuários da LAN que usam o Outlook estão tentando acessar enquanto o certificado fica em seu IIS ou Exchange.

Caso contrário, os usuários serão solicitados a informar "Incompatibilidade de nome de certificado SSL" e, em alguns casos, serão solicitados a digitar suas senhas repetidamente.

Responder2

Estou lutando exatamente contra esse problema. Não tenho pontos suficientes para apenas comentar.

Mas estou curioso, você tem o provedor de Outlook EXCH CertPrincipalName definido?

Get-OutlookProvider

É normal que os certificados curinga precisem definir o provedor EXPR. Mas estou descobrindo que também preciso definir o provedor EXCH para clientes RPC.

Set-OutlookProvider EXCH -CertPrincipalName msstd:*.domain.com

informação relacionada