Alerta de segurança do Outlook - O nome no certificado de segurança é inválido ou não corresponde ao nome do site

14

SBS 2008 executando o Exchange 2007 e IIS6.0

A CompanyA possui duas outras empresas que operam sob o mesmo teto. Para acomodar email, temos 3 contas do Exchange por usuário para gerenciar isso. Todos os usuários usam suas contas CompanyA para fazer login no domínio.

O email funciona bem internamente e via OWA. O problema existe ao configurar o Outlook para usuários remotos que precisam acessar os emails companyB e companyC, o Outlook exibe o erro de certificado.

A certificação SSL da SAN possui os seguintes nomes DNS:

  • webmail.companyA.com
  • www.webmail.companyA.com
  • CORP-SBS
  • CORP-SBS.local
  • autdiscover.companyA.com

Os usuários que acessam o endereço de e-mail da empresaC me disseram remotamente que isso nunca acontecia antes. Isso começou com o CEO alterar os provedores de DNS por conta própria e, no processo, as configurações originais de DNS foram perdidas. Ele mencionou algo sobre a criação de um registro SRV que corrigiu esse problema, mas é isso.

Procurando orientação sobre como lidar com isso adequadamente.

Mike66350216
fonte

Respostas:

25

Esse problema provavelmente é causado pelo serviço de Descoberta Automática do Outlook , parte da funcionalidade do Outlook em Qualquer Lugar . A descoberta automática fornece várias informações ao cliente Outlook do usuário final sobre os vários serviços oferecidos pelo Exchange e onde eles podem ser localizados; isso é usado para vários propósitos:

  • Configuração automática de perfis do Outlook na primeira execução do Outlook, que pode configurar uma conta do Exchange usando apenas o endereço de email e a senha do usuário, pois as outras informações são localizadas e recuperadas automaticamente.

  • Localização dinâmica de serviços baseados na Web acessados ​​pelo cliente Outlook, incluindo o assistente de ausência temporária, a funcionalidade de Unificação de Mensagens, a localização do Painel de Controle do Exchange (ECP) e assim por diante.

Esta é a implementação proprietária da Microsoft do RFC 6186 . Infelizmente, eles realmente não seguiram as recomendações dessa RFC no design do Outlook em Qualquer Lugar, mas talvez isso seja esperado, já que a funcionalidade Exchange e RPC sobre HTTPS não é um servidor IMAP / SMTP tradicional.


Como a Descoberta Automática funciona (para usuários externos *)?

A descoberta automática se comunica com um serviço da Web em um Servidor de Acesso para Cliente (nesse caso, todas as funções estão no servidor SBS) no caminho /Autodiscover/Autodiscover.xml, com raiz do site padrão. Para localizar o FQDN do servidor com o qual se comunicar, ele remove a parte do usuário do endereço de email, deixando o domínio (por exemplo, @ companyB.com). Ele tenta se comunicar com a Descoberta Automática usando cada um dos seguintes URLs, por sua vez:

  • https://companyB.com/Autodiscover/Autodiscover.xml
  • https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

Se eles falharem, ele tentará uma conexão não segura desativando o SSL e tentando se comunicar na porta 80 (HTTP), normalmente após solicitar ao usuário que confirme que esta é uma ação aceitável (uma opção falha na minha opinião, pois os usuários sem noção irão normalmente aprova isso e corre o risco de enviar credenciais em texto sem formatação - e os administradores de sistemas sem noção que não exigem comunicação segura de credenciais e dados sensíveis aos negócios são um risco para a continuidade dos negócios).

Finalmente, é feita uma verificação subseqüente usando um registro de serviço (SRV) no DNS, que existe em um local conhecido fora do companyB.comespaço para nome e pode redirecionar o Outlook para o URL apropriado onde o servidor está escutando.


O que pode dar errado?

Um dos vários problemas pode surgir nesse processo:

Nenhuma entrada DNS

Normalmente, a raiz do domínio ( companyB.com) pode não ser resolvida para um registro de host no DNS. A configuração incorreta do DNS (ou uma decisão consciente de não expor o serviço Outlook em Qualquer Lugar) pode significar que o autodiscover.companyB.comregistro também não existe.

Nesses casos, não há grande problema; O Outlook simplesmente continua a se comunicar com o Exchange usando a última configuração conhecida e pode ser degradado com relação a determinadas funções baseadas na Web, para as quais ele precisa recuperar URLs através da Descoberta Automática (como o assistente de ausência temporária). Uma solução alternativa é usar o Outlook Web Access para acessar essas funções.

A configuração automática de contas do Exchange em novos perfis do Outlook também não é automatizada e requer configuração manual das configurações de RPC sobre HTTPS. No entanto, isso não causará o problema que você descreve.

Certificados SSL com defeito

É perfeitamente possível que o URL que o Outlook usa para tentar entrar em contato com o Exchange Server resolva para um host, que pode ou não ser um Servidor de Acesso para Cliente. Se o Outlook puder se comunicar com esse servidor na porta 443, é claro que os certificados serão trocados para configurar um canal seguro entre o Outlook e o servidor remoto. Se o URL que o Outlook acredita que está falando não estiver listado nesse certificado - seja como o nome comum ou um nome alternativo de assunto (SAN) - isso fará com que o Outlook apresente a caixa de diálogo que você descreve na postagem inicial.

Isso pode acontecer por vários motivos, tudo sobre como o DNS está configurado e como os URLs que descrevi acima são verificados pelo Outlook:

  • Se a https://companyB.com/URL ... for resolvida para um registro de host e o servidor da Web nesse endereço ouvir na porta 443, e tiver um certificado SSL que não esteja listado companyB.comno nome comum ou no Nome Alternativo do Assunto, o problema ocorrerá. Não importa se o host é um servidor Exchange ou não; pode ser um servidor da web que hospeda um site da empresa que não está configurado corretamente. Corrige :

    • Desabilite o registro do host na raiz da companyB.comzona (exigindo a entrada de visitantes do site ou outro serviço www.companyB.comou equivalente; ou
    • Desabilite o acesso à máquina na companyB.comporta 443, fazendo com que o Outlook rejeite a companyB.comURL antes que os certificados sejam trocados e prossiga; ou
    • Corrija o certificado em companyB.compara garantir que companyB.comesteja listado nesse certificado e que as tentativas de visita https://companyB.comem um navegador padrão não falhem.

    O acima se aplica independentemente de a companyB.comresolução ser resolvida no Exchange Server; se o Outlook puder se comunicar com ele, descobrirá mais tarde que o /Autodiscover/Autodiscover.xmlcaminho gera um erro HTTP 404 (não existe) e seguirá em frente.

  • Se o https://autodiscover.companyB.com/URL ... for resolvido para o Exchange Server (ou qualquer outro servidor) mas, novamente, autodiscover.companyB.comnão estiver listado como o nome comum ou um nome alternativo do assunto, você observará esse comportamento. Ele pode ser fixado como acima, fixando o certificado, ou como você indicar corretamente, você pode usar um registro SRV para redirecionar o Outlook para uma URL que está listada no certificado e que Outlook pode se comunicar com.

Sua provável correção para esse problema

Nesse caso, a correção típica é fazer a última; crie registros SRV no novo provedor DNS para garantir que o Outlook seja redirecionado autodiscover.companyA.com, o qual (quaisquer outros problemas à parte) funcionará com êxito, pois está listado no certificado como uma SAN. Para que isso funcione, você precisa:

  • Configure um _autodiscover._tcp.companyB.comregistro SRV de acordo com a documentação .
  • Exclua o autodiscover.companyB.comregistro do host, se existir, para impedir que o Outlook resolva isso e tente alcançar a Descoberta Automática dessa maneira.
  • Resolva também quaisquer problemas com o acesso HTTPS https://companyB.comconforme acima, pois o Outlook enumera os URLs derivados do endereço de email do usuário antes de recorrer à abordagem de registro SRV.

* Como a Descoberta Automática funciona (para clientes internos ingressados ​​no domínio)?

Eu adiciono isso apenas para fins de integridade, pois é outro motivo comum para a solicitação desses certificados.

Em um cliente ingressado no domínio, quando é local no ambiente do Exchange (ou seja, na LAN interna), as técnicas acima não são usadas. Em vez disso, o Outlook se comunica diretamente com um Ponto de Conexão de Serviço no Active Directory (listado nas configurações de Acesso para Cliente do Exchange), que lista a URL onde o Outlook pode localizar o serviço de Descoberta Automática.

É comum que avisos de certificado ocorram nessas circunstâncias, porque:

  • O URL padrão configurado para esse fim se refere ao URL interno do Exchange, que geralmente é diferente do URL público.
  • Os certificados SSL podem não listar a URL interna neles. No momento, o seu é o caso, mas isso pode se tornar um problema no futuro para domínios do Active Directory que usam .localsufixos não globais de nomes de domínio semelhantes a gTLDs, já que uma decisão da ICANN proíbe que certificados SSL para esses domínios sejam emitidos após 2016.
  • O endereço interno pode não ser resolvido no servidor apropriado.

Nesse caso, o problema é resolvido corrigindo a URL registrada para se referir ao endereço externo apropriado (listado no certificado), executando o Set-ClientAccessServercmdlet com a -AutodiscoverServiceInternalUriopção As partes que fazem isso normalmente também configuram o DNS com horizonte dividido , porque são obrigadas a fazê-lo por sua configuração de rede e / ou pela continuidade da resolução no caso de uma interrupção de conexão / resolver upstream.

Ossifragem Cósmica
fonte
2
Excelente redação! Embora eu acredite que, na última seção, deve ser o Service Connection Point (SCP), em vez do Service Locator Point (SLP).
precisa saber é o seguinte
@BlueCompute, de fato, você está certo, tive minha cabeça no System Center há muito tempo recentemente! (As SLPs costumavam existir no SCCM 2007 e serviam a um propósito remotamente relacionado ao SCP). Corrigido o acima
Ossifrage Cósmica
Obrigado pela escrita completa! Acabei de perceber que autodiscover.companyA.com é um registro A e não um registro CNAME. Isso terá algum impacto no registro SRV funcionando corretamente para companyB.com?
precisa saber é o seguinte
1
O suporte público para registros SRV ainda está um pouco ausente, mesmo entre os provedores de DNS. Parece que você resolveu o problema!
Ossifrage cósmica
3
Eu só quero ressaltar que sua escrita maravilhosa + o seguinte link resolveu meu problema. superuser.com/questions/770308/… . Só queria deixar essa nota aqui para qualquer um que estivesse no mesmo barco que eu.
James Watt
3

Você precisa criar um registro SRV nos domínios B e C que corresponda a um dos nomes no certificado (autodiscover.companyA.com). Isso informa ao Outlook que esse nome lida com a descoberta automática dos domínios B e C.

Leia aqui os registros SRV na seção DNS:

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/

joeqwerty
fonte
1
O link está quebrado ...
Eu digo Reinstate Monica
@Twisty Corrigido o link.
Alexander Gonchiy 31/03