☰

Der Name des Sicherheitszertifikats ist ungültig oder stimmt nicht mit dem Namen der Site überein

tag-icon • tag-icon ssl exchange-2013
Der Name des Sicherheitszertifikats ist ungültig oder stimmt nicht mit dem Namen der Site überein

Unser Exchange-Server läuft seit einiger Zeit mit einem intern signierten Zertifikat. Heute habe ich ein vertrauenswürdiges SSL-Zertifikat (Wilcard) gekauft und auf dem Server installiert.

Das Zertifikat ist an *.example.no ausgestellt und gibt keine Sicherheitsausnahmen, wenn ich https://mail.example.no/owaüber den Webbrowser auf die Weboberfläche zugreife.

Wenn ich jetzt Outlook öffne, erhalte ich diesen Zertifikatsvalidierungsfehler. Ich habe alle angebotenen Standardlösungen ausprobiert, bei denen es meistens darum ging, die externe URL als interne URL festzulegen.

  • Interner FQDN:mx.example.local
  • Externer FQDN:mail.example.no
  • Fehlermeldung: Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Zielsite mx.example.local überein. Outlook kann keine Verbindung zum Proxyserver herstellen. (Fehlercode 10)

Was ich getan habe:

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

Das Ergebnis:

[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

Danach habe ich

  • Den IIS-Anwendungspool MSExchangeAutoDiscoverAppPool wiederverwendet (dadurch ist die Meldung nicht verschwunden, also habe ich ...)
  • Habe den gesamten Mailserver neugestartet (dadurch ist die Nachricht auch nicht verschwunden, also habe ich ...)
  • Bin in die Systemsteuerung -> Mail -> E-Mail-Konten gegangen und habe „Mein Konto reparieren“ gewählt (da ich diesen Beitrag schreibe, haben Sie vielleicht schon vermutet, dass dies auch keine Wirkung hatte).
  • DNS des Client-Computers geleert (falls die Autodiscover-URL ignoriert wurde)
  • Habe das E-Mail-Konto noch einmal repariert
  • Habe versucht, das Konto zu bearbeiten und den öffentlichen FQDN mail.example.no als Serveradresse einzugeben
  • BEARBEITEN: Habe versucht, das Konto zu löschen und neu zu erstellen. Habe das gesamte E-Mail-Profil sowie die Ordner %AppData%\Local\Outlook und %AppData%\Local\Outlook gelöscht. Immer noch kein Erfolg.

Mir gehen jetzt die Ideen aus ... jede Site, die ich im Internet besucht habe, suggeriert, dass ich das tue, was ich gerade getan habe, und dass das Ergebnis genau meinem Ergebnis entsprechen soll ...

AKTUALISIEREN: Einer meiner Benutzer kann sich nicht einmal von seiner Arbeitsstation aus mit Outlook anmelden. Das Konto ist in Ordnung (Mail auf Mobiltelefon und Webclient funktioniert), aber Outlook wiederholt ständig die Kennwortabfrage und beendet den Offlinemodus nicht.

AKTUALISIEREN: Habe auf der Digicert-Website eine SSL-Prüfung durchgeführt, um zu sehen, ob das Zertifikat ordnungsgemäß installiert ist. Der Server hat alle Prüfungen bestanden, ich wurde nur vor der Verwendung des SSL 3.0-Protokolls gewarnt: Protokollunterstützung TLS 1.1, TLS 1.0, SSL 3.0. SSL 3.0 ist eine veraltete Protokollversion mit bekannten Schwachstellen.

AKTUALISIERUNG 150709:

Haftungsausschluss: Bei diesem Update wurden keine echten internen IP-Adressen beschädigt.

  • Ich habe eine neue Forward Lookup Zone im DNS eingerichtet, mail.example.nomit einem leeren (A) Eintrag, der auf 192.168.1.1 verweist, die hypothetische IP-Adresse des Mailservers
  • In der Reverse Lookup Zone für 192.168.1.in-adds.arpa habe ich einen (PTR)-Eintrag mit dem Namen 192.168.1.1, der auf mail.example.no verweist
  • HeruntergeladenDigiCert® Internal Name Tool für Microsoft Exchange
  • Habe das Tool ausgeführt, die Adressen waren größtenteils korrekt, aber OWAVirtualDirectory ECPVirtualDirectory verwies immer noch auf mx.example.local, also habe ich sie in mail.example.no geändert.

nslookupDie Ausgabe sieht vielversprechend aus:

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

Outlook funktioniert nicht.....

Kleiner Test:

  1. Gehen Sie zu „Kontoeinstellungen“ -> „Weitere Einstellungen“ -> „Verbindung“ -> „Exchange-Proxy-Einstellungen“.
  2. Die Verbindungs-URL wurde geändert inhttps://mail.example.no
  3. Der zulässige Hauptname wurde geändert inmsstd:*.example.no
  4. Outlook neu gestartet. Der Zertifikatsfehler tritt jetzt nicht mehr auf, aber ich stelle fest, dass ich nicht verbunden bin ...
  5. Kontoeinstellungen noch einmal, dieses Mal habe ich die automatische Reparatur gewählt
  6. Outlook neu gestartet
  7. Wenn ich jetzt zu den Exchange-Proxy-Einstellungen zurückgehe, wird die interne URL zurückgegeben ...

Antwort1

Das Zertifikat des Drittanbieterausstellers muss Ihren internen FQDN als alternativen Antragstellernamen enthalten, um mit Ihrer lokalen AutoErmittlung funktionieren zu können, die LAN-Benutzer mit Outlook zu erreichen versuchen, da sich das Zertifikat auf Ihrem IIS oder Exchange befindet.

Andernfalls wird den Benutzern die Meldung „SSL-Zertifikatsname stimmt nicht überein“ angezeigt und sie werden in einigen Fällen aufgefordert, ihr Passwort immer wieder einzugeben.

Antwort2

Ich kämpfe genau mit diesem Problem. Ich habe nicht genug Punkte, um nur einen Kommentar abzugeben.

Aber ich bin neugierig, haben Sie den CertPrincipalName des EXCH-Outlook-Anbieters festgelegt?

Get-OutlookProvider

Bei Wildcard-Zertifikaten ist es üblich, den EXPR-Anbieter festlegen zu müssen. Ich stelle jedoch fest, dass ich möglicherweise auch den EXCH-Anbieter für RPC-Clients festlegen muss.

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

verwandte Informationen