web-dev-qa-db-fra.com

Alerte de sécurité Outlook - Le nom sur le certificat de sécurité n'est pas valide ou ne correspond pas au nom du site

SBS 2008 exécutant Exchange 2007 et IIS6.0

CompanyA a deux autres sociétés qui opèrent sous le même toit. Pour gérer les e-mails, nous avons 3 comptes Exchange par utilisateur pour gérer cela. Tous les utilisateurs utilisent leur compte CompanyA pour se connecter au domaine.

Le courrier électronique fonctionne bien en interne et via OWA. Le problème existe lors de la configuration d'Outlook pour les utilisateurs distants qui ont besoin d'accéder aux e-mails de la société B et de la société C, Outlook affiche l'erreur de certificat.

Le certificat SSL SAN a les noms DNS suivants:

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

Les utilisateurs qui accèdent à distance à l'adresse e-mail de companyC m'ont dit que cela ne s'était jamais produit auparavant. Cela a commencé avec le changement de fournisseur DNS par le PDG et, au cours du processus, les paramètres DNS d'origine ont été perdus. Il a mentionné quelque chose sur la création d'un enregistrement SRV qui corrigeait ce problème, mais c'est à peu près tout.

Vous cherchez des conseils sur la façon de résoudre correctement ce problème.

sslexchangeoutlookcertificate
14
Mike66350216

Ce problème est probablement dû au service de découverte automatique d'Outlook , qui fait partie de la fonctionnalité Outlook Anywhere. La découverte automatique fournit diverses informations au client Outlook de l'utilisateur final sur les différents services offerts par Exchange et sur leur emplacement; il est utilisé à diverses fins:

  • Autoconfiguration des profils Outlook lors de la première exécution d'Outlook, qui peut configurer un compte Exchange en utilisant uniquement l'adresse e-mail et le mot de passe de l'utilisateur, car les autres informations sont automatiquement localisées et récupérées.

  • Emplacement dynamique des services Web accessibles par le client Outlook, y compris l'assistant d'absence du bureau, la fonctionnalité de messagerie unifiée, l'emplacement du panneau de configuration Exchange (ECP), etc.

Il s'agit de l'implémentation propriétaire de Microsoft RFC 6186 . Malheureusement, ils n'ont pas vraiment suivi les recommandations de ce RFC dans la conception d'Outlook Anywhere, mais cela est peut-être à prévoir car la fonctionnalité Exchange et RPC sur HTTPS n'est pas un serveur IMAP/SMTP traditionnel.

Comment fonctionne la découverte automatique (pour les utilisateurs externes *)?

La découverte automatique communique avec un service Web sur un serveur d'accès au client (dans ce cas, tous les rôles sont sur le serveur SBS) sur le chemin /Autodiscover/Autodiscover.xml, dérivé de son site Web par défaut. Pour localiser le nom de domaine complet du serveur avec lequel communiquer, il supprime la partie utilisateur de l'adresse e-mail, laissant le domaine (c'est-à-dire @ companyB.com). Il tente à son tour de communiquer avec la découverte automatique à l'aide de chacune des URL suivantes:

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

Si ceux-ci échouent, il tentera une connexion non sécurisée en désactivant SSL et en tentant de communiquer sur le port 80 (HTTP), généralement après avoir invité l'utilisateur à confirmer qu'il s'agit d'une action acceptable (une option imparfaite à mon avis, car les utilisateurs désemparés généralement approuver cela et risquer d'envoyer des informations d'identification sur du texte brut - et les administrateurs système ignorants qui ne nécessitent pas une communication sécurisée des informations d'identification et des données sensibles à l'entreprise sont un risque pour la continuité des activités).

Enfin, une vérification de suivi est effectuée à l'aide d'un enregistrement de service (SRV) dans le DNS, qui existe à un emplacement bien connu au large du companyB.com espace de noms et peut rediriger Outlook vers l'URL appropriée où le serveur écoute.

Qu'est-ce qui peut mal tourner?

Un de plusieurs problèmes peut survenir dans ce processus:

Aucune entrée DNS

En règle générale, la racine du domaine (companyB.com) peut ne pas se résoudre en enregistrement d'hôte dans le DNS. Une configuration DNS incorrecte (ou une décision consciente de ne pas exposer le service Outlook Anywhere) peut signifier que le autodiscover.companyB.com l'enregistrement n'existe pas non plus.

Dans ces cas, il n'y a pas de problème majeur; Outlook continue simplement à communiquer avec Exchange à l'aide de la dernière configuration connue et peut être dégradé en ce qui concerne certaines fonctions Web pour lesquelles il doit récupérer des URL via la découverte automatique (comme l'assistant d'absence du bureau). Une solution de contournement consiste à utiliser Outlook Web Access pour accéder à ces fonctions.

La configuration automatique des comptes Exchange dans les nouveaux profils Outlook n'est pas non plus automatisée et nécessite une configuration manuelle des paramètres RPC sur HTTPS. Toutefois, cela ne provoquera pas le problème que vous décrivez.

Certificats SSL défectueux

Il est tout à fait possible que l'URL utilisée par Outlook pour tenter de contacter le serveur Exchange se résout en un hôte, qui peut ou non être un serveur d'accès au client. Si Outlook peut communiquer avec ce serveur sur le port 443, des certificats seront bien sûr échangés pour configurer un canal sécurisé entre Outlook et le serveur distant. Si l'URL qu'Outlook croit discuter n'est pas répertoriée sur ce certificat - que ce soit en tant que nom commun ou autre nom de sujet (SAN) - cela provoquera Outlook pour présenter la boîte de dialogue que vous décrivez dans votre message initial.

Cela peut se produire pour plusieurs raisons, toutes liées à la configuration du DNS et à la façon dont les URL que j'ai décrites ci-dessus sont vérifiées par Outlook:

  • Si la https://companyB.com/... L'URL se résout en un enregistrement d'hôte, et le serveur Web à cette adresse écoute sur le port 443, et il a un certificat SSL qui ne pas liste companyB.com dans le nom commun ou le nom alternatif du sujet, le problème se produit. Peu importe que l'hôte soit un serveur Exchange ou non; il peut s'agir d'un serveur Web hébergeant un site Web d'entreprise qui n'est pas correctement configuré. Corrige soit:

    • Désactivez l'enregistrement d'hôte à la racine du companyB.com zone (obliger les visiteurs du site Web ou d'un autre service à entrer www.companyB.com, ou équivalent; ou
    • Désactivez l'accès à la machine à companyB.com sur le port 443, ce qui oblige Outlook à rejeter le companyB.com URL avant que les certificats ne soient échangés et continuent; ou
    • Fixez le certificat à companyB.com s'assurer companyB.com est répertorié sur ce certificat et tente de visiter https://companyB.com dans un navigateur standard n'échouent pas.

    Ce qui précède s'applique indépendamment du fait que companyB.com se résout sur le serveur Exchange; si Outlook peut communiquer avec lui, il découvrira plus tard que le /Autodiscover/Autodiscover.xml chemin renvoie une erreur HTTP 404 (n'existe pas) et continuez.

  • Si la https://autodiscover.companyB.com/... L'URL est résolue vers le serveur Exchange (ou tout autre serveur) mais, encore une fois, autodiscover.companyB.com n'est pas répertorié en tant que nom commun ou autre nom de sujet, vous observerez ce comportement. Il peut être corrigé comme ci-dessus en corrigeant le certificat, ou comme vous l'indiquez à juste titre, vous pouvez utiliser un enregistrement SRV pour rediriger Outlook vers une URL qui est répertorié sur le certificat et avec lequel Outlook peut communiquer avec.

Votre solution probable à ce problème

Dans ce cas, la solution typique consiste à faire ce dernier; créer des enregistrements SRV dans le nouveau fournisseur DNS pour garantir que Outlook est redirigé vers autodiscover.companyA.com, qui (tout autre problème mis à part) fonctionnera correctement car il est répertorié sur le certificat en tant que SAN. Pour que cela fonctionne, vous devez:

  • Configurer un _autodiscover._tcp.companyB.com Enregistrement SRV conformément à la documentation .
  • Supprimez le autodiscover.companyB.com Enregistrement d'hôte, s'il existe, pour empêcher Outlook de résoudre ce problème et de tenter d'atteindre la découverte automatique de cette manière.
  • Résolvez également tous les problèmes d'accès HTTPS à https://companyB.com comme ci-dessus, car Outlook énumérera les URL dérivées de l'adresse e-mail de l'utilisateur avant passant à l'approche d'enregistrement SRV.

* Comment fonctionne la découverte automatique (pour les clients internes joints à un domaine)?

J'ajoute cela simplement pour être complet, car c'est une autre raison courante pour que ces invites de certificat se produisent.

Sur un client joint à un domaine, lorsqu'il est local à l'environnement Exchange (c'est-à-dire sur le LAN interne), les techniques ci-dessus ne sont pas utilisées. Au lieu de cela, Outlook communique directement avec un point de connexion de service dans Active Directory (répertorié dans les paramètres d'accès au client Exchange), qui répertorie l'URL où Outlook peut localiser le service de découverte automatique.

Il est courant que des avertissements de certificat se produisent dans ces circonstances, car:

  • L'URL par défaut configurée à cet effet fait référence à l'URL interne d'Exchange, qui est souvent différente de l'URL publique.
  • Les certificats SSL peuvent ne pas y lister l'URL interne. À l'heure actuelle, le vôtre le fait, mais cela pourrait devenir un problème à l'avenir pour les domaines Active Directory qui utilisent .local et des suffixes de noms de domaine gTLD non mondiaux similaires, car ne décision de l'ICANN interdit la délivrance de certificats SSL pour ces domaines après 2016.
  • L'adresse interne peut ne pas être résolue sur le serveur approprié.

Dans ce cas, le problème est résolu en corrigeant l'URL enregistrée pour faire référence à l'adresse externe appropriée (répertoriée dans le certificat), en exécutant Set-ClientAccessServer applet de commande avec -AutodiscoverServiceInternalUri commutateur. Les parties qui le font configurent généralement également DNS à horizon partagé , soit parce qu'elles sont tenues de le faire par leur configuration réseau et/ou pour la continuité de la résolution en cas de résolveur/panne de connexion en amont.

25
Cosmic Ossifrage

Vous devez créer un enregistrement SRV dans les domaines B et C qui correspond à l'un des noms du certificat (autodiscover.companyA.com). Cela indique à Outlook que ce nom gère la découverte automatique pour les domaines B et C.

Lisez ici les enregistrements SRV dans la section DNS:

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

3
joeqwerty