Zertifikatsfehler: Der Name im Zertifikat stimmt nicht überein..., Outlook-Client verwendet .local

Zertifikatsfehler: Der Name im Zertifikat stimmt nicht überein..., Outlook-Client verwendet .local

Wir mussten vor Kurzem unser .localZertifikat von Godaddy außer Betrieb setzen, da es nicht mehr gültig ist. Das neue Zertifikat enthält die folgenden Namen:

  • mail.meinedomain.com
  • autodiscover.meinedomain.com

Dieses Zertifikat wurde auf dem Exchange-Server angewendet und für alle Dienste aktiviert.

Ich hatte damit gerechnet, dass Clients Fehlermeldungen zum Zertifikat erhalten, da sie mit dem mail.mylocaldomain.localNamen verknüpft sind. Ich habe viel Dokumentation gelesen und alle sagen so ziemlich dasselbe:

  1. neue Zone auf dem lokalen DNS-Server mit der öffentlichen Domäne hinzufügen (ich habe eine Zone hinzugefügt mydomain.com)
  2. Fügen Sie einen Datensatz A hinzu, der auf die lokale IP des E-Mail-Servers verweist (ich habe mail.mydomain.comeinen Verweis auf die lokale IP des Servers hinzugefügt)

Ich habe diese Befehle ausgegeben:

Set-ClientAccessServer -Identity EXCHANGE-MAIL -AutodiscoverServiceInternalUrihttps://mail.publicdomain.co.uk/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “EXCHANGE-MAIL\EWS (Default Web Site)” –InternalUrlhttps://mail.publicdomain.co.uk/EWS/Exchange.asmx
Set-OABVirtualDirectory -Identity “EXCHANGE-MAIL\OAB (Default Web Site)” -InternalURL https://mail.publicdomain.co.uk/OAB
Set-ActiveSyncVirtualDirectory -Identity “EXCHANGE-MAIL\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURLhttps://mail.publicdomain.co.uk/Microsoft-Server-Activesync
Set-WebServicesVirtualDirectory –Identity ‘EXCHANGE-MAIL\EWS (Default Web Site)’ –ExternalUrlhttps://mail.publicdomain.co.uk/ews/exchange.asmx

mit den richtigen Namen darin, aber meine Clients erhalten immer noch den Zertifikatsfehler.

Warum?

Antwort1

Der FQDN (Fully Qualified Domain Name) Ihres Exchange-Servers lautet immer noch hostname.domainname.local. Daher stellen die Clients eine Verbindung zu ihm her, erkennen, dass der Name des Servers, zu dem sie eine Verbindung herstellen, weder mit dem Namen noch mit den SANs (Subject Alternative Names) auf Ihrem Zertifikat übereinstimmt, und geben wie vorgesehen diesen Fehler aus.

Die (bei weitem) einfachste Lösung besteht darin, eine Exchange-Migration durchzuführen, um Ihren Exchange-Server in eine ordnungsgemäß benannte Domäne zu verschieben, für die Sie ein von einer vertrauenswürdigen öffentlichen Zertifizierungsstelle ausgestelltes Zertifikat erhalten können.

Lesen Sie diesen Thread zu Best Practices für Active Directory., es ist eines von mehreren, die wir zu diesem Thema haben. Ihr Active Directory-DNS-Name sollte eine unbenutzte Subdomäne Ihres öffentlich registrierten Domänennamens sein. Sobald Sie das eingerichtet haben, migrieren Sie Ihren Exchange-Server dorthin und lassen Sie sich ein Zertifikat ausstellen, das den FQDN Ihres neuen Exchange-Servers enthält, für den Sie ein Zertifikat erhalten können.

Antwort2

bitte beachten Sie, dass die Antwort von HopelessN00b NICHT korrekt ist. Sie müssen den Exchange NICHT migrieren, selbst wenn er den lokalen Hostnamen hat. Das Hinzufügen einer internen DNS-Zone, die auf den öffentlichen Namen verweist, ist ebenso möglich wie das Ändern des Schalters autodiscoverinternaluri.

Antwort3

Zur Lösung lesen Sie bitte den folgenden Microsoft KB-Artikel (940726): http://support.microsoft.com/en-us/kb/940726

Outlook fragt AD regelmäßig ab, um die AutoErmittlungseinstellungen zu aktualisieren. Daher kann es bis zu einer Stunde dauern, bis Outlook die neuen Einstellungen übernimmt (oder Sie können Outlook neu starten, um die Einstellungen sofort zu aktualisieren).

Überprüfen Sie außerdem, ob mail.mydomain.com auf die interne IP-Adresse des Exchange-Servers auf Outlook-Clients verweist und ob Sie den MSExchangeAutodiscoverAppPool in IIS auf dem Exchange-Server nach dem Anwenden der neuen Einstellungen erneut verwendet haben.

verwandte Informationen