zeroblue2005
Goto Top

Exchange 2016 und OWA bzw. Zertifikate

Hallo Zusammen,

jetzt wo ich meinen Exchange am laufen habe, möchte ich natürlich auch gerne, dass dieser via HTTPS://domain/owa erreichbar ist. Auf Grund dass ich meine Server an einem Dyn-DSL ohne feste IP betreibe, ist klar dass ich ohne die blöden Warnmeldungnen nicht drum herum komme. Das stört mich aber auch nicht. Klickt man auf OK und weiter.

Jetzt wo mein neuer Exchange 2016 am laufen ist, bekomme ich aber nur noch angezeigt:

Diese Website ist nicht erreichbar
ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

Es kommt keine Warnung auf ungültiges SSL Zerti. sondern wird direkt geblockt! Wenn ich einen alten FireFox nehme, klappt es! Komisch für mich ist nur, dass mein Apache auch ein eigenes Zerti hat was ich unterschrieben habe. Das klappt weiterhin.

Also muss es doch alleine ein Problem sein, was mit dem Zerti vom Exchange zu tun hat oder? Lustigerweise habe ich noch einen alten Exchange 2010, da klappt es immer noch mit OWA!

Die Zielsetzung ist es nicht, keine Warnmeldung zu erhalten, sondern ich würde gerne wissen, warum FireFox und Chrome das Zerti vom Exchange 2010 durchlassen und vom 2016 nicht?

Danke

Content-Key: 330819

Url: https://administrator.de/contentid/330819

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: 132272
Lösung 132272 01.03.2017 aktualisiert um 15:14:02 Uhr
Goto Top
Mitglied: zeroblue2005
zeroblue2005 01.03.2017 um 14:55:30 Uhr
Goto Top
Danke, dass muss man erst mal wissen face-smile
Mitglied: ketanest112
ketanest112 01.03.2017 um 17:54:20 Uhr
Goto Top
Prinzipiell hat ein SSL Zertifikat nichts mit einer Dyn. IP zu tun, denn das SSL Zertifikat wird i.d.R. auf einen Domainnamen ausgestellt.
Das Problem kenne ich, das taucht des öfteren beim Wechsel des Zertifikats auf.
Evtl. muss du unter Server Manager -> IIS -> (Servername) -> Verwaltungsdienst dein Zertifikat eintragen/auswählen, das fliegt gerne mal raus.
Außerdem muss das Zertifikat in beiden Sites (Default und Exchange Backend) in der SSL Bindung hinterlegt sein.

Zumindest war das beim meinem 2013er immer wieder mal ein Problem.

Grüße
Ketanest
Mitglied: zeroblue2005
zeroblue2005 02.03.2017 um 10:02:43 Uhr
Goto Top
Hallo,

leider muss ich euch noch mal bemühen. Jetzt habe ich das Problem, dass zwar OWA läuft und auch wenn ich mich von einem Client im lokalen Netzwerk via Outlook anmelde und dort sage: Jep Exchange Kompatibler Dienst ist vorhanden, mach mal, konfiguriert er das Postfach von selbst. Es kommt zwar die blöde Warnmeldung, aber egal! Auch Smartphones klappt wunderbar!

Was nicht geht ist, dass ich mit meinem Laptop eine VPN via IP-Sec herstelle ins Netzwerk L2TP und versuche wie früher das Outlook Konto zu konfigurieren. Ich habe hier bisher immer bei Serveradresse die IP eingetragen und vorher in der ETC\HOST einen Eintrag auf den Exchange gemacht.

Die DNS Auflösung klappt auch, jedoch bekomme immer die Meldung:

exchange

Was mache ich falsch oder habe ich vergessen was zu konfigurieren?

Danke
Mitglied: 132272
132272 02.03.2017 aktualisiert um 10:57:44 Uhr
Goto Top
Mitglied: zeroblue2005
zeroblue2005 02.03.2017 um 14:23:48 Uhr
Goto Top
Mist, jetzt habe ich alles so gemacht wie es beschrieben war, jeden Schritt 10 mal geprüft...

und jetzt geht nichts mehr....

Bis hier hin bin ich gekommen:
https://www.frankysweb.de/exchange-2016-zertifikate-konfigurieren-teil-2 ...

Bei:
Zertifikatsanforderung abschließen und Dienste zuweisen

Jetzt kann ich das AdminCenter nicht mehr aufrufen...

Jetzt stehe ich auf dem Schlauch....
Mitglied: 132272
132272 02.03.2017 aktualisiert um 14:26:37 Uhr
Goto Top
In der "Backend"-Website (IIS-Konsole) das richtige SSL-Zertifikat auswählen und einen IISRESET machen.
Mitglied: zeroblue2005
zeroblue2005 02.03.2017 aktualisiert um 15:01:15 Uhr
Goto Top
Irgendwas läuft verkehr ich habe oben in der IIS Konsole auf Serverzertifikate geklickt und dann auf Zertifikatsanforderung. Dort dann die Antwortdatei *.crt eingelesen und Zertispeicher Persönlich ausgewählt.

Hiernach wird mir das Zerti auch angezeigt mit Namen den ich vergeben habe und nach neustart des IIS ist er es weg....

Was mache ich nun falsch? Kommt nur immer Seite kann nicht geladen werden.
Mitglied: 132272
132272 02.03.2017 aktualisiert um 15:02:43 Uhr
Goto Top
VOLLKOMMEN FALSCH!
Öffne die Backend Website im IIS und gehe in die Bindungen setze dort das SSL-Zertifikat auf das was du generiert oder schon eingebunden hast!!

Herr je morgen ist schon wieder Freitag ...Liest hier eigentlich keiner mehr irgendwelche Dokus???
Mitglied: zeroblue2005
zeroblue2005 02.03.2017 um 16:24:43 Uhr
Goto Top
Du, ich sitze hier sein ca. 48 Stunden an der Sache mit dem Exchange und gelesen habe ich so viel, das es mir aus den Ohren kommt.
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 07:47:02 Uhr
Goto Top
Hallo Zusammen,

ich habe das Ganze oben von Franky noch mal ganz von vorne durchgearbeitet. Da der aufgesetzte Exchange eine VM ist, hatte ich mit dafür Punkte gesetzt. Ebenfalls habe ich mir wie auf der Seite SSL-Start ein Zerti geholt und auch wie beschrieben über den Exchange installiert und den Diensten zugeordnet. Auch wenn ich mir sicher bin, das ich alles richtig gemacht habe, laut Anleitung:

- virtuele Verzeichnisse angepasst OK
- DNS Einträge OK
- Zerti OK

usw.

Bekomme ich immer nach den einspielen bzw. Dienstzuordnung des Zerti von SSl-Start und neustart des Servers folgende Meldung im FireFox oder IE:


Ein Fehler ist während einer Verbindung mit mail.domain.eu aufgetreten. Das Zertifikat der Gegenstelle wurde widerrufen. Fehlercode: SEC_ERROR_REVOKED_CERTIFICATE

In den Logs steht:
Der WWW-Publishingdienst (WWW-Dienst) konnte das URL-Präfix "https://*:443/ecp" für die Website "1" nicht registrieren. Die erforderliche Netzwerkverbindung wird möglicherweise bereits verwendet. Die Website wurde deaktiviert. Das Datenfeld enthält die Fehlernummer

Natürlich habe ich im IIS die Bindung des Zerti kontrolliert. Finde jedoch keine Lösung. Ich habe auch viel google gefragt u. gelesen. Ich komme nicht weiter....

Kurz zur Info, ich habe den Exchange die ganze Zeit via RDP konfiguriert, dass kann ja nicht das Problem sein oder, das hier ggf. die Zertis kollidieren oder so was?

Wenn ich im übrigen die Seite owa anspreche und absichtlich ein nicht vorhandenes Verzeichnis angebe wie blabla, also mail.domain.eu/blabla

Dann ist klar kommt ne Fehlermeldung vom IIS, jedoch das Zerti von SSL-Start wird mir als sicher angezeigt, also keine Warnmeldung!

Was läuft da verkehrt?
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 09:55:14 Uhr
Goto Top
Jetzt bin ich einen Schritt weiter! Das ganze ist wohl ein Problem von SSL-Start und FireFox...
Mitglied: 132272
132272 03.03.2017 aktualisiert um 10:14:49 Uhr
Goto Top
Klar, die CA von StartSSL wurde als nicht mehr vertrauenswürdig gebrandmarkt! Vor allem die Certs mit den alten Roots.
Sagt ja schon die Fehlermeldung sofern man sich grundlegend mit Zertifikaten auskennt.
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 10:25:49 Uhr
Goto Top
Sorry ich hatte keine Ahnung, setze mich mich den schei...Zertis das erste mal auseinder. bestelle mir jetzt ein richtiges....
Mitglied: 132272
132272 03.03.2017 aktualisiert um 10:49:39 Uhr
Goto Top
Zitat von @zeroblue2005:
Sorry ich hatte keine Ahnung, setze mich mich den schei...Zertis das erste mal auseinder. bestelle mir jetzt ein richtiges....
Für den Test reicht auch ein selbst ausgestelltes oder eines von Let's Encrypt , gerade wenn du davon noch keinen Schimmer hast denn sonst zahlst du hinterher noch doppelt ...
https://www.frankysweb.de/exchange-2016-kostenlose-zertifikate-von-lets- ...
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 11:00:06 Uhr
Goto Top
Danke für die Info. Habe jetzt hier: https://www.psw-group.de/ssl-zertifikate/detail/c44-geotrust-quickssl-pr ...

eines bestellt für 39 €
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 13:42:51 Uhr
Goto Top
Ich beisse echt gleich ins Grans!!!! Jetzt habe ich Stunden über Stunden damit verbracht, alles richtig zu machen und habe Frankys Anleitung nicht nur einmal sondern zich mal durch. Bis auf das etwas kaputte Start-SSL, läuft alles.

Dann wollte ich gerade einen Test machen:

- Client in der AD mit Outlook OK
- Zugriff über OWA von xxx Client OK
- Zugriff über Android Client OK
- Zugriff aus Client mit Outlook im selben IP-Netzwerk ???

Kommt wieder der gleiche Fehler wie in Beitrag Nr 02.03.2017 um 10:02 Uhr EAS ...

Ein NS Lookup von diesem Client zeigt aber das alles OK ist

Ich drehe so langsam am Rad... Warum kann ich mich mit keinen Outlook Client ausserhalb der Domäne verbinden unabhängig des Zerti?

Was kann ich noch machen?
Mitglied: 132272
132272 03.03.2017 aktualisiert um 13:51:32 Uhr
Goto Top
Zugriff aus Client mit Outlook im selben IP-Netzwerk ???
Kommt wieder der gleiche Fehler wie in Beitrag Nr 02.03.2017 um 10:02 Uhr EAS ...
Bitte nur Autodiscover nutzen, nicht manuell einrichten.

Wie wird jetzt bei dir gearbeitet? Du hast zwei Domains im Zertifikat?:
  • mail.domain.de
  • autodiscover.domain.de

Dann solltest du intern Split-DNS betreiben, denn wenn dein Router Loopback-NAT nicht checkt -> Ende Gelände!

Anleitung lesen schön und gut, nur sollte man das was dahinter steckt auch verstehen warum und wieso, sonst bringt das ganze nichts...
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 14:04:12 Uhr
Goto Top
OK ich versuche mal darauf zu antworten!

Wie wird jetzt bei dir gearbeitet? Du hast zwei Domains im Zertifikat?: = Ja

Zum Thema Split DNS! Keine Ahnung ob und ob er das kann!

Fakt ist. Der Exchange und der Client der nicht Mietglied der Domäne sind, nutzen den gleichen DNS Server im gleichen IP-Netzwerk!

Autodiscover hin oder her , warum kann ich Outlook nicht auf die alte Weise am Exchnage anmelden? So wie beim 2010. Da hat man auf manuell geklickt und bei Server die IP eigegeben und alles war gut!

Es kann doch nicht sein, dass das jetzt bei 2016 überhaupt nicht mehr geht oder? Auch wenn es auf die Sicherheit gehen sollte, wäre ich dankbar dafür, wenn mir jemand sagen kann wo ich da schrauben muss.
Mitglied: 132272
132272 03.03.2017 aktualisiert um 14:51:47 Uhr
Goto Top
Zum Thema Split DNS! Keine Ahnung ob und ob er das kann!
Sorry dann hast du den Artikel von Frank nicht vernünftig gelesen!! Das ist dort essentieller Bestandteil und auch der Grund warum es bei dir intern nicht läuft.

Es kann doch nicht sein, dass das jetzt bei 2016 überhaupt nicht mehr geht oder?
Doch, 2013 war noch Schonfrist, ab jetzt nur noch mit einwandfrei eingerichtetem Autodiscover.
Also mach es einmal richtig dann haben deine Clients auch keine Probleme mehr!

Punkt.

Ich bin jetzt raus hier, das wird mich jetzt ehrlich gesagt zu blöd, wenn man hier alles doppelt und dreifach verzellen muss und man für blöde hingestellt wird face-sad

Ciao
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 15:11:54 Uhr
Goto Top
Ich glaube wir beide sprechen nicht die gleiche Sprache. Natürlich habe ich den DNS-Split drin stand ja auch in der Anleitung! Ich verstehe jetzt nur nicht warum du beleidigt bist? Ich habe lediglich gesagt ICH WEISS NICHT OB MEIN ROUTER Loopback-NAT kann.

Wobei ich eben die Frage gestellt habe, was der Router damit zu tun hat, wenn beide Rechner (Exchnage u. Client) im gleichen lokalen Netzwerk stehen? Die Autodiscover anfrage wird doch über den DNS aufglöst oder täusche ich mich da?

Also Ergo muss er doch nach der ganzen Konfigs. den Exchnage finden.

Gebe ich am Client nslookup mail.domain.de ein dann bekomme ich vom DNS in der AD die Antwort 192.168.178.217 und das ist ja der Exchnage. Daher frage ich mich was der Router damit zu tun hat!

Wenn der Autodisover natürlich erst an den Provider geht, wo ich die Domäne der Mailadresse hoste und von da keine Antwort kommt dann wirst du wohl recht haben.

Ja schöne ###e macht das Projekt nicht schöner aber dann muss ich anders arebeiten dann ist es halt so
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 15:49:27 Uhr
Goto Top
So Problem gelöst face-smile

Die Ursache war dem test.user der eine Standardmailadresse ausserhalb der Zertifizierten Domainen hatte. Hier kurz die Daten:

Name des Exchnage: VM-Exchange1
Domaine: Domain.local
FQDN: VM-Exchange1.Domain.local

Regestrierte Domainen beim Provider:
mail.domain.eu
autodiscover.domain.eu

Der Testuser hatte daher von Haus aus folgende Mailadressen:
test.user@Domain.local

Dann habe ich dem test.user via akzeptierte RelayDomain eine Mailadresse von domain.de verpasst, die ich dann als Antwortadresse eingetragen habe.

Auch wenn ich beim Provider für die domaine.de autodisover deaktiviert habe und auch einen SRV-Record eintrag gesetzt hatte, klappte die Anmeldung nicht!

Jetzt habe ich den Exchnage ein wenig veräppelt, mal sehen ob das gut geht! Ich habe dem Test.user eine Mailadresse aus denm Zertifizierten domain.eu verpasst und die als Anmeldung benutzt und siehe einer an, ging sofort!

Dann habe ich im Exchange die Antwortadresse wieder gewechselt und den client und Exchnage drei mal neu gestartet und es geht immer noch.

Also für alle, die das Problem auch mal haben sollten...
Mitglied: 132272
132272 03.03.2017 aktualisiert um 16:45:10 Uhr
Goto Top
Es hätte auch gereicht einen A-Record mit "autodiscover" in der local Domain anzulegen.
Nur mal so nebenbei, mit *.local bekommst du noch Spaß mit Apple Geräten face-wink, denn dieser Suffix ist dort für Multicast reserviert.

Optimalerweise sollte man auch den UPN der AD-Accounts mit der e-Mail Adresse abgleichen und den genutzten externen Domain-Suffix unter Domains und Trusts hinzufügen, dann ist das vernünftig umgesetzt und im Autodiscover-Prozess muss das Passwort dann nicht doppelt eingeben werden.
Mitglied: zeroblue2005
zeroblue2005 03.03.2017 um 17:02:00 Uhr
Goto Top
Da sind wir das erste mal beide einer Meinung! Das stimmt....

schönes Wochenende