Exchange 2016: Zertifikate konfigurieren (Teil 2)

Dies ist der zweite Teil der Artikelserie. Wie schon im ersten Teil angekündigt, befasst sich dieser Artikel mit der Konfiguration.

Wichtig: Vorher unbedingt den ersten Teil lesen, da dieser Artikel direkt darauf aufbaut.

Konfiguration Exchange 2016

Der erste Teil endete mit den Überlegungen für die URLs mit denen auf Exchange zugegriffen werden soll. Der Einfachheit halber hier noch einmal die Tabelle mit den URLs:

Dienst / ProtokollDNS-Name
OWA (Interne URL)https://mail.frankysweb.de/owa
OWA (externe URL)https://mail.frankysweb.de/owa
OAB (interne URL)https://mail.frankysweb.de/OAB
OAB (externe URL)https://mail.frankysweb.de/OAB
ActiveSync (interne URL)https://mail.frankysweb.de/Microsoft-Server-ActiveSync
ActiveSync (externe URL)https://mail.frankysweb.de/Microsoft-Server-ActiveSync
MAPI (interne URL)https://mail.frankysweb.de/mapi
MAPI (externe URL)https://mail.frankysweb.de/mapi
EWS (interne URL)https://mail.frankysweb.de/EWS/Exchange.asmx
EWS (externe URL)https://mail.frankysweb.de/EWS/Exchange.asmx
ECP (interne URL)https://mail.frankysweb.de/ecp
ECP (externe URL)https://mail.frankysweb.de/ecp
Outlook Anywhere (Intern)mail.frankysweb.de
Outlook Anywhere (extern)mail.frankysweb.de
Autodiscover (Intern)https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml

Die Konfiguration der URLs ist für Autodiscover wichtig. Diese URLs werden durch Autodiscover an Outlook verteilt, somit findet Outlook den entsprechenden Exchange Server. Werden die virtuellen Verzeichnisse nicht mit entsprechenden URLs konfiguriert, kommt es später wieder zu Zertifikatsfehlern. Es ist also genau darauf zu achten, dass für jedes virtuelle Verzeichnis eine entsprechende interne und externe URL gesetzt wird. Autodiscover verteilt sonst falsche URLs an die Clients.

Die URLs können per Exchange Administrative Center eingestellt werden, hier für OWA:

image

hier für ECP:

image

Auf diese Weise werden alle virtuellen Verzeichnisse konfiguriert, mit Ausnahme von “Powershell” und “Autodiscover”. “PowerShell” und “Autodiscover” werden _NICHT_ verändert und erhalten keine neuen URLs:

image

Es werden also nur die folgenden virtuellen Verzeichnisse mit den URLs aus der Tabelle gefüllt:

  • owa
  • OAB
  • Microsoft-Server-ActiveSync
  • mapi
  • EWS
  • ecp

 

Nachdem die virtuellen Verzeichnisse konfiguriert wurden, kann auch der Hostname für Outlook Anywhere vergeben werden, auch dies ist wieder per Exchange Administrative Center möglich:

image

Eine kleine Ausnahme bildet die Autodiscover URL für den CAS-Dienst, diese kann nur per Exchange Management Shell gesetzt werden. In der Standardeinstellung ist auch hier der interne Servername eingetragen:

image

Mit dem folgenden Befehl wird die URL entsprechend geändert:

Set-ClientAccessService EX1 -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"

image

Nachdem diese Schritte durchgeführt wurden, kann der IIS Server mittels “iisreset” neu gestartet werden:

image

Die Exchange Konfiguration ist soweit fertig, weiter geht es mit den erforderlichen DNS Einträgen.

DNS Konfiguration

Exchange hört nach den oben durchgeführten Schritte nur noch auf mail.frankysweb.de und Autodiscover auf autodiscover.frankysweb.de. Damit diese beiden FQDNs nun auch im internen Netzwerk, sowie auch aus dem Internet (HomeOffice) auflösbar sind, müssen entsprechende DNS Einträge konfiguriert werden.

Noch einmal kurz der Ablauf der Kommunikation (vereinfacht)

Ein interner Rechner hat als DNS Server üblicherweise den Domain Controller konfiguriert. Outlook auf dem internen Rechner wird zunächst autodiscover.frankysweb.de anfragen um den Exchange Server zu finden. Der DNS Server auf dem Domain Controller antwortet auf die Anfrage des Clients mit der internen IP Adresse des Exchange Servers. Der Client ruft die Konfiguration ab und fragt dann wiederum den internen DNS Server nach mail.frankysweb.de. Das Bild stellt die DNS Anfragen und Antworten vereinfacht dar (grüne und roter Pfeile):

DNS

Ähnliches gilt für Clients im HomeOffice. Auf den meisten Routern wird ein DNS-Forwarder laufen. Dieser DNS Forwarder auf dem Router reicht die DNS Anfragen des Clients aus dem HomeOffice an entsprechende DNS-Server im Internet weiter. Hier gibt es zwar noch mehrere beteiligte DNS-Server, aber schlussendlich wird der DNS-Server des Hosters auf die Autodiscover reagieren müssen. Die Anfragen zu autodiscover.frankysweb.de und mail.frankysweb.de, sollen nun mit der externen IP-Adresse des Internetanschlusses des Unternehmens beantwortet werden. Die Outlook Verbindung wird also diesen Weg gehen (blaue Pfeile)

Verbindung

Intern wird sich Outlook mit mail.frankysweb.de verbinden welches auf die interne IP-Adresse des Exchange Servers zeigt. Extern wird es ebenso mail.frankysweb.de sein, nur mit dem Unterschied, dass jetzt die externe IP aufgelöst wird.

Dazu müssen die DNS Server entsprechend konfiguriert werden:

Internen DNS Server konfigurieren

Da Autodiscover nach erfolgter Konfiguration nun die URLs wie oben angegeben verteilen wird, müssen die URLs nun auch verfügbar sein. Auf dem Domain Controller werden die DNS-Zonen etwa wie folgt aussehen:

image

Da das ActiveDirectory in diesem Fall auf den Namen frankysweb.local hört, gibt es dazu zwei entsprechende interne Zonen und normalerweise auch eine Reverse Lookup Zone mit den entsprechenden Subnetzen.

Intern muss Exchange nun aber über den Namen mail.frankysweb.de und autodiscover.frankysweb.de erreichbar sein, denn diese Namen wurden entsprechend konfiguriert. Daher wird zunächst eine neue DNS Zone erstellt:

image

Als Zonentyp wird “Primäre Zone” belassen:

image

Auch die Zonenreplikation kann so belassen werden:

image

Als Zonenname wird “mail.frankysweb.de” eingetragen:

image

Dynamische Updates können abgeschaltet werden:

image

Innerhalb der neuen Zone wird nun ein neuer HOST-A Eintrag angelegt:

image

Für den HOST-A Eintrag wird _KEIN_ Name konfiguriert. Im Feld IP-Adresse wird die interne IP des Exchange Servers angegeben und das Häkchen bei “Verknüpften PTR-Eintrag erstellen” entfernt:

image

Somit sollte es nun wie folgt aussehen:

image

Die Schritte werden entsprechend für Autodiscover wiederholt. Eine weitere Neue Zone mit dem Namen “Autodiscover.frankysweb.de” wird angelegt:

image

Und auch in der Zone autodiscover.frankysweb.de wird ein HOST-A Eintrag mit der internen IP des Exchange Servers angelegt:

image

Mittels nslookup können nun die beiden Zonen überprüft werden.

Autodiscover.frankysweb.de und mail.frankysweb.de müssen von einem internen Client/Rechner/Server auf die interne IP des Exchange Servers verweisen:

image

Konfiguration externer DNS (Hoster)

Damit der Exchange Server nun auch aus dem Internet (HomeOffice) unter dem Namen mail.frankysweb.de erreichbar ist, müssen entsprechende DNS Einträge beim Hoster der Domain gesetzt werden. Je nach Hoster (Strato, 1und1, HostEurope etc.) verläuft die Konfiguration hier etwas unterschiedlich. In diesem Beispiel ist es Strato:

Zuerst werden zwei neue Subdomains angelegt:

image

Einmal die Subdomain mit dem Namen “mail”, woraus sich “mail.frankysweb.de” ergibt:

image

Gleiches für die Subdomain mit dem Namen “autodiscover”, woraus sich autodiscover.frankysweb.de ergibt.

image

Für beide Subdomains wird jetzt ein A-Record definiert:

image

Als IP-Adresse wird die externe IP-Adresse des Internetanschlusses des Unternehmens angegeben:

image

Hinweis: Hier handelt es sich um die WAN-IP des Routers / Firewalls des Unternehmens.

Die WAN-IP wird für autodiscover und mail eingegeben. Die Übersicht der Domain sollte nun in etwa so aus sehen:

ExtDNS

Autodiscover.frankysweb.de und mail.frankysweb.de verfügen über je einen A-Record mit der externen IP Adresse des Unternehmens.

Die DNS Auflösung mittels nslookup sollte jetzt die externe IP für autodiscover.frankysweb.de und mail.frankysweb.de zurückliefern:

image

Es fehlt jetzt noch die Portweiterleitung am Router des Unternehmens damit der Exchange Server auch unter Port 443 erreichbar ist.

Konfiguration Portweiterleitung am Router / Firewall

Die END-Einträge wurden nun konfiguriert, allerdings fehlt noch eine Portweiterleitung am Router des Unternehmens, damit der Exchange Server auch via Port 443 aus dem Internet erreichbar ist. Auch hier ist die Einrichtung wieder abhängig vom eingesetzten Router oder Firewall. Auch der Name variiert hier von Hersteller zu Hersteller, NAT-Regel, Portforward, DNAT, Portweiterleitung oder Portfreigaben sind hier gängige Begriffe.

Die Logik dahinter ist folgende:

Eine Verbindung, die an der externen IP Adresse des Routers auf einem bestimmten Port ankommt, wird weitergeleitet an eine interne IP-Adresse und Port.

Hinweis: Die Einrichtung einer Portweiterleitung macht den Exchange Server aus dem Internet via Port 443 erreichbar. Besser wäre der Einsatz einer entsprechenden Firewall bzw. Proxys (hier ein Beispiel) zwischen Internet und Exchange Server. Die Einrichtung ist aber nicht Gegenstand dieses Artikels.

Falls das Unternehmen über eine Fritzbox verfügt, funktioniert die Einrichtung einer Portfreigabe wie folgt:

image

Wie im Screenshot zu erkennen ist, wird nur der Port 443 (TCP) an die interne IP des Exchange Servers auf Port 443 weitergeleitet.

Das rote Tuch (Exchange Zertifikat)

Zum Schluss ist das “rote Tuch” besser bekannt als Zertifikat an der Reihe. Wenn die Vorbereitungen allerdings alle abgeschlossen wurden, ist es jetzt kein Problem mehr.

Noch einmal kurz zum Hintergrund:

In der voran gegangene Konfiguration wurden die virtuellen Verzeichnisse und die Outlook Anywhere Konfiguration soweit angepasst, das diese auf mail.frankysweb.de hören, aus diesem FQDN ergeben sich dann die entsprechenden URLs mit denen die Verzeichnisse (interne und externe URLs) entsprechend konfiguriert wurden. Internes und Externes DNS wurden ebenfalls so konfiguriert, dass der Exchange Server unter diesen URLs erreichbar ist. Somit sind für das Zertifikat nur die folgenden FQDNs von Bedeutung:

  • mail.frankysweb.de
  • autodiscover.frankysweb.de

Mehr muss nicht auf dem Zertifikat stehen. Nur diese beiden Namen. Falls sich jetzt schon jemand fragen sollte: Was ist denn wenn ich mehrere Domains habe und auch E-Mail Adressen mit beispielsweise “@frankysweb.com”? Weiterlesen, kommt noch…

Um die Zertifikatsanforderung zu speichern, sollte vorab ein Ordner angelegt werden. Am besten auf dem Exchange Server selbst unter C:\. In diesem Fall ist es C:\Zertifikat:

image

Jetzt kann die Zertifikatsanforderung erstellt werden.

Zertifikatsanforderung erstellen

Damit eine Zertifizierungsstelle ein Zertifikat ausstellen kann, wird eine Zertifikatsanforderung benötigt. Die Zertifikatsanforderung teilt der Zertifizierungsstelle die Eigenschaften für das Zertifikat mit. Um bei den Ausweisbeispiel zu bleiben: Die Zertifikatsanforderung ist der Antrag auf einen Ausweis, wobei der Antrag den Namen, Adresse usw. enthält. Der Antrag (Zertifikatsanforderung) muss jetzt von von einer Behörde/Land (Zertifizierungsstelle) ausgestellt werden.

Eine Zertifikatsanforderung kann via Exchange Admin Center erstellt werden:

image

Als Anzeigename wird “mail.frankysweb.de” eingetragen:

image

Der nächste Dialog kann so belassen werden, hier muss nichts ausgewählt werden:

image

Gespeichert wird das Zertifikat auf EX1 dem Exchange Server:

image

Im darauf folgenden Dialog werden alle URLs noch einmal angezeigt:

image

Wer die Liste durchscrollt, wird feststellen, das hier noch interne Servernamen und URLs angezeigt werden. Auch diese können so belassen werden:

image

Im nächsten Dialog lassen sich die Einträge für das Zertifikat bearbeiten, hier wird jetzt alles gelöscht, sodass nur noch “mail.frankysweb.de” und “autodiscover.frankysweb.de” überbleibt.

Vorher:

image

Nachher:

image

Jetzt müssen noch ein paar Angaben vervollständigt werden. Organisationsname entspricht dabei den Firmenname, der Abteilungsname kann frei gewählt werden, Ort, Bundesland und Land sollte klar sein:

image

Zum Schluss wird der Speicherort für die Zertifikatsanforderung angegeben. Im Vorfeld wurde dazu der Ordner c:\Zertifikat auf dem Exchange Server angelegt. Dieser Ordner kann nun per Administrativer Freigabe angesprochen werden:

image

Die Anforderung wurde erstellt im Admin Center ist nun eine ausstehende Anforderung zu sehen:

image

Ausstehende Anforderung bedeutet in diesem Fall soviel wie: Antrag ausgefüllt, aber noch kein Ausweis ausgestellt.

Unter C:\Zertifikat findet sich nun eine Datei mit dem Namen “Anforderung.txt”. Diese Datei enthält den Antrag für die Zertifizierungsstelle, auch “Certificate Signing Request” (CSR) genannt:

image

Der Antrag (CSR) muss nun bei einer Zertifizierungsstelle eingereicht werden.

Zertifikat von einer offiziellen Zertifizierungsstelle anfordern

Die zuvor generierte Anforderung muss nun bei einer Zertifizierungsstelle eingereicht werden. Die Zertifizierungsstelle stellt dann ein entsprechendes Zertifikat aus.

Wie schon mehrfach erwähnt müssen zwei Namen auf dem Zertifikat (SAN Zertifikat) vorhanden sein (autodiscover.frankysweb.de und mail.frankysweb.de). So steht es auch in der generierten Anforderung. Bei dem Reseller PSW gibt es recht günstig ein entsprechendes Zertifikat:

https://www.psw-group.de/ssl-zertifikate/detail/c44-geotrust-quickssl-premium/

3 Jahre Gültigkeit kosten 99 EUR. Verschiedene andere CAs bieten Zertifikate auch kostenlos an, wobei als wohl bekanntester Vertreter StartSSL Probleme mit Mozilla bekommen hat (StartSSL und auch WooSign haben es nicht ganz so genau mit der eigenen Sicherheit genommen).

Der Prozess wie eine Anforderung eingereicht werden muss, ist aber bei den meisten Zertifizierungsstellen ähnlich:

  1. Anmelden
  2. Zertifikatsanforderung einreichen
  3. Valdierung durchlaufen (das Verfahren kann unterschiedlich sein, meistens eine Mail an webmaster@domain.tld oder hostmaster@domain.tld)
  4. Zertifikat erhalten
  5. Bezahlen (ggf. auch kostenlos)

Trotz der Probleme bei StartSSL lassen sich weiterhin Zertifikate beantragen, da wie schon der Prozess bei den meisten Zertifizierungsstellen relativ ähnlich ist, folgt hier das Beispiel mit StartSSL. Die Anmeldung wurde bereits abgeschlossen:

Bei StartSSL müssen dann die beiden DNS-Namen angegeben und der Inhalt der Datei Anforderung.txt hochgeladen werden:

image

Nach entsprechender Validierung durch die Zertifizierungsstelle erhält man das Zertifikat. Für Testumgebungen lässt sich StartSSL weiterhin wunderbar verwenden, ich nehme an das die Probleme mit Mozilla in absehbarer Zeit geklärt werden.

Für produktive Umgebung würde ich empfehlen ein Zertifikat zu kaufen, der Preis aus dem oben genannten Beispiel ist sicherlich nicht zu hoch und bei 3 Jahren Laufzeit durchaus erschwinglich.

Sobald man das Zertifikat von der Zertifizierungsstelle erhalten hat (meistens per Download oder per Mail), kann es auf dem Exchange Server unter C:\Zertifikat abgespeichert werden.

Die meisten Zertifizierungsstellen stellen das Zertifikat in verschiedenen Formaten aus. Exchange Server kann mit .CER und .CRT Dateien umgehen. In diesem Beispiel ist es eine .CRT Datei:

image

Zertifikatsanforderung abschließen und Dienste zuweisen

Sobald das Zertifikat im Ordner C:\Zertifikat abgespeichert wurde, kann die Austehende Anforderung abgeschlossen werden. Dieser Vorgang kann wieder mittels Exchange Admin Center erfolgen:

image

Im Dialog wird dann wieder die Administrative Freigabe und der Name des Zertifikats angegeben:

image

Sobald die Anforderung abgeschlossen wurde, wird das Zertifikat mit “Gültig” gekennzeichnet:

image

Jetzt ist zwar ein gültiges Zertifikat vorhanden, aber dieses Zertifikat wurde noch nicht den Exchange Diensten zugeordnet.

Damit Exchange dieses Zertifikat auch künftig verwendet, muss es an die relevanten Dienste gebunden werden, dazu werden die Eigenschaften des Zertifikats per Doppelklick geöffnet und die folgenden Dienste zugewiesen:

  • SMTP
  • IMAP
  • POP
  • IIS

 

image

Die Warnung muss bestätigt werden, dann wird das Zertifikat ausgetauscht:

image

Ab jetzt benutzt Exchange das neue Zertifikat.

Überprüfung

Zur Überprüfung können nun mehrere Tests durchgeführt werden.

Zunächst kann die DNS Auflösung von internen sowie externen Rechnern getestet werden:

image

Intern muss die interne IP des Exchange Servers aufgelöst werden, extern die entsprechende IP des Routers mit der Portweiterleitung.

Dann kann Outlook Web Access von internen sowie externen Rechnern aufgerufen werden, jeweils unter den Namen mail.frankysweb.de. Beim Aufruf darf nun keine Zertifikatswarnung mehr auftreten:

Exchange 2016 Zertifikate

In den Details des Zertifikat unter dem Punkt “Alternativer Antragsstellername” müssen beide Namen hinterlegt sein:

image

Outlook zeigt im Verbindungsstatus nur mail.frankysweb.de als Servernamen an, interne Namen dürfen hier nicht mehr vorkommen:

image

Der Outlook Modus “E-Mail Autokonfiguration testen” liefert nur noch URLs mit https://mail.frankysweb.de/… zurück

Exchange Remote Connectivity Analyzer lässt für den Autodiscover Test sauber durch:

image

Bei der URL “https://frankysweb.de:443/Autodiscover” darf es zu einem Fehler kommen, da Exchange nicht unter dieser URL erreichbar ist, für die URL https://autodiscover.frankysweb.de:443/autodisover” muss es sauber durchlaufen (Ohne Zertifikatswarnung)

image

Nachtrag

Dies war die grundlegende Konfiguration mit einer E-Mail Domain und einem offiziellen Zertifikat. Nun gibt es natürlich noch weitere Fälle mit einer internen Zertifizierungsstelle oder mehreren E-Mail Domänen. Das wird dann ein Fall für Teil 3 (bereits in Arbeit, wird verlinkt wenn fertig).

60 Replies to “Exchange 2016: Zertifikate konfigurieren (Teil 2)”

  1. Moin Moin,
    super und nochmals vielen Dank. So könnte ich jetzt unsere Probleme angehen und das endlich mal VERNÜNFTIG konfigurieren.

    Bei zwei Schritten hänge ich…
    1. meine Cmdlets nimmt er nicht – (in früheren Schulungen hab ich das wohl mal gelernt – muß ich in der Console erst mal was laden, dass er mir die nimmt?!) -Get-ClientAccessService xxxxx usw.
    2. beim Speichern der Anforderung (nach der Anleitung) bringt er mir einen Fehler „Verwenden Sie einen gültigen Dateinamen, wenn Sie das Cmdlet „New-ExchangeCertificate“ auf dem Server xxx-xxx mit dem Parameter RequestFile ausführen. Die Datei darf nicht im Zielordner vorhanden sein. Parametername: RequestFile“

    Vielleicht kann mir hier jemand helfen -> Danke
    Gruß Swen

  2. Scheint jetzt alles zu laufen! Vielen lieben Dank noch einmal für deinen Beitrag!!!

    Evtl. doch noch eine Frage… was für ZERTIFIKATE müssen im Exchange da sein.
    Ich hab insgesamt 3 Stück: 1. mein Zertifikat was (vorerst) von StartSSL kommt (mail.meinedomain.de) 2. ein Zertifikat das „keinen Namen“ hat (Aussteller: cn=exchange.domain.local) Dienste: IIS 3. Zertifikat ist Microsoft Exchange Server Auth Certificate Dienste: SMTP…

    Hat mir jemand noch einen Tipp, was für welche benötigt werden!? bzw. kann ich das OHNE NAMEN entfernen?!
    Danke
    Gruß Swen

  3. Wie müsste ich das Ganze anpassen, wenn ich statt einer festen IP dyndns nutzen würde?

    Also Exchange 2016 -> Holt per POP3 die Mails von einem Postfach bei Strato ab und verschickt sie über den Smarthost bei Strato. (Mail: username@xyz.de )

    Der Zugriff über Outlook, OWA, etc. erfolgt allerdings über zxy.dyndns.org.

    Muss ich jetzt mail.zxy.dyndns.org und autodiscover.zxy.dyndns.org einrichten?
    Also stelle ich das Zertifikat genau so aus, wie du mit frankysweb.de nur mit zxy.dyndns.org?
    Oder benötige ich dafür irgendwas bestimmtes?

  4. Vielen Dank für diesen Artikel – ich habe schon ewig nach einer verständliche Erklärung für die Zertifikatseinrichtung gesucht.
    Kleine Fragen hätte ich da noch:
    1. darf ein SAN-Zertifikat auf mehreren Maschinen laufen? Beispielsweise haben wir ja eine SPAM-Appliance die Mails von außen zuerst annimmt und sich als unser Mailserver ausgibt.
    2. Ich muss ja vermutlich von jeder Maschine die das Zertifikat erhält eine eigene csr erstellen, müssen die Angaben da identisch sein, also auch autodiscover etc. enthalten, oder sagt man in der csr dann nur mail.domain.de?
    3. Da man ja im SAN-Zertifikat auch noch weitere Namen angeben kann, ist es OK auch noch weitere Server zu adressieren wie gate.domain.de und das Zertifikat an den Stellen ebenfalls zu nutzen? Dann könnte man ja alle externen Zugänge wie Citrix-Gateways oder ähnliches mit nur einem Zertifikat versorgen, und das wäre prima..

    Viele Grüße
    Peter

  5. Hi,

    zu 1: Ja, du kannst das Zertifikat auf mehreren Systemen einsetzen, solange der private Schlüssel exportierbar ist.
    zu 2: Du kannst das vorhandene Zertifikat nutzen und exportieren und dann auf dem Zielsystem importieren.
    zu 3: siehe 1 und 2. Ja, das kann man machen.

    Gruß, Frank

  6. Hallo Frank – das hilft ungemein weiter. Ich habe lange mit verschiedenen teueren Einzelzertifikaten gearbeitet, und kann das endlich vernünftig gestalten.
    Aber wenn man von Zertifikate zu wenig Ahnung hat wird einem eben alles angedreht ;-)

    Nochmals Danke für die Klarstellung
    Peter

  7. Hi Peter,
    wenn du das gleiche Zertifikat auf mehreren Systemen einsetzt, solltest du dokumentieren auf welchen Systemen dieses Zertifikat zum Einsatz kommt. Wenn du zum Beispiel das gleiche Zertifikat für Exchange und einen anderen Dienst verwendest, musst du es auch bei beiden Systemen aktualisieren wenn es aufläuft.
    Bei einer größerem Anzahl von DNS-Namen auf dem Zertifikat lohnt sich auch ggf. ein Wildcard Zertifikat. Ein Wildcard Zertifikat enthält dann den Eintrag *.Domain.de, somit sind alle Namen unterhalb von Domain.de (owa.domain.de, Firewall.domain.de, abc.domain.de) adressierbar. Gerade in diesem Fall wird eine saubere Dokumentation wichtig. Wildcard Zertifikate gibt es schon ab ca. 100. EUR pro Jahr.
    Gruß, Frank

  8. Hallo Frank,
    Danke für die gute und detaillierte Anleitung zu Zertifikaten. Wir hatten auch immer Probleme mit Meldungen und Warnungen zum Zertifikat auf unseren Exchange. Nun habe ich mich letzte Woche ran gemacht und deine Anleitung abgearbeitet. Sieht jetzt sehr gut aus. Bis heute keine Zertifikatswarnung an irgendeinem Rechner. Eine Meldung wirft Outlook jetzt noch aus. „Konfigurieren von Nutzer@firma.de-Servereinstellungen für diese Website zulassen? https://autoconfigure.strato.de/autodiscover/autodiscover.xml …“ Geh ich richtig der Annahme, dass das der Autodiscover-Dienst von Strato ist? Soll ich das zulassen oder soll ich den Dienst in Strato deaktivieren?

  9. Hallo Michael,
    richtig, das ist der Autodiscover Dienst von Strato, dieser muss deaktiviert werden und „der eigene“ wie beschrieben konfiguriert werden.
    Gruß, Frank

  10. Hallo Frank,

    ich musste bei meinem Server Exchange 2013 CU11 bei „Autodiscover URL für den CAS-Dienst“ anstatt Set-ClientAccessService den Befehl Set-ClientAccessServer eintragen. Den anderen hat er nicht akzeptiert, obwohl es in deiner Shell ok aussah.

    Aber es läuft top mit deiner Anleitung. Vielen Dank!

    Gruß Herta

  11. Hallo
    richtig, bei einem Exchange 2013 Server heißt es noch „Set-ClientAccessServer“ anstatt „Set-ClientAccessService“. Ich ergänze den Artikel mit einem entsprechenden Hinweis.
    Gruß, Frank

  12. Hallo,

    vielen Dank für die Anleitung. Anhand dieser habe ich einen Exchange 2013 Server mit einen SAN Zertifikat installiert.
    Leider bekomme ich immer den Fehler auf den Clients:
    „Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor.
    Der Name des Sicherheitszertifikats ist ungültig oder entspricht nicht dem Namen der Zielwebsite ‚mail.domäne.de‘.
    Von Outlook kann keine Verbindung mit dem Proxyserver hergestellt werden (Fehlercode: 10).“
    oder eine Zertifikatsverwarnung das der Name nicht über einstimmt, obwohl die Namen im Zertifikat mail.domäne.de
    und autodiscover.domäne.de angeben sind und auch im Exchange eingerichtet sind.

  13. Hallo Maik,
    ich nehme an dass nicht alle Virtuellen Verzeichnisse entsprechend der URL (intern sowie extern) konfiguriert wurden. (Outlook Anywhere nicht vergessen)
    Gruß, Frank

  14. Hallo Frank,

    danke für deine schnelle Antwort, aber alle Virtuellen Verzeichnisse sind umgestellt auch Outlook Anywhere.
    Beim manchen Client bekomme ich eine Fehlermelder, bei anderen funktioniert es ohne.

    Virtuelle Verzeichnisse: WebservicesVirtualDirectory, OWAVirtualDirectory, ECPVirtualDirectory,
    ActiveSyncVirtualDirectory, OABVirtualDirectory,
    Internal: mail.domäne.de
    External: mail.domäne.de

    Outlook Anywhere: ClientAccessServer
    autodiscover.domäne.de

    Ich habe schon überall nach gesehen, finde aber nicht den Punkt, wo der lokal Servername noch verwendet wird.

  15. Hallo Frank und alle Anderen,

    erst mal Danke für die detaillierte Anleitung!
    Hat soweit alles einwandfrei funktioniert – allerdings nur mit dem IE und Edge.

    Kann es sein, dass der Chrome und der Firefox ein Problem mit dem Split DNS haben?

    Sowohl intern als auf beim externen Zugriff erhalte ich im Chrom diese Fehlermeldung:
    ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
    und im Firefox diese: Fehlercode: NS_ERROR_NET_INADEQUATE_SECURITY

    Wie gesagt mit dem IE und dem Edge sowohl intern und extern kein Problem. Mit den anderen Browser nicht möglich :-(

    Kann mir da event. jemand weiterhelfen?

    Gruss

    Alex

  16. Hallo Frank,
    ich habe eine Frage zur Anpassung des internen DNS: In Deinem Beispiel wird eine neu Zone „mail.frankysweb.de“ angelegt. Warum nicht eine Zone „frankysweb.de“ und in dieser einen Host-A Eintrag „mail“? Wie würde man verfahren wenn Deine interne (AD) Domäne split-brain wäre, also anstatt „frankysweb.local“ ebenfalls „frankysweb.de“?
    Danke für Deine super Anleitungen!

  17. @Maik, @Frank, Hallo,
    habe jetzt das gleiche Problem wie Maik:
    Schritt für Schritt nach Anleitung von Frank umgesetzt (auf Exchange2016 CU3 mit Outlook2016-Clients),
    alles funktioniert wie erwartet,außer Outlook2016 -> Zertifikatsfehler! Outlook bekommt immer noch den
    alten internen Servernamen „ex1.meinedomäne.de“ präsentiert wo hingegen das neue Zertifikat auf „mail.meinedomäne.de“ lautet. Alle URLs intern+extern(owa,OAB,Microsoft-Server ActiveSync, mapi, EWS, ec, Outlook Anywhere) auf „mail.meinedomäne.de“ sowie autodiscover intern auf „autodiscover.meinedomäne.de“ angepasst. Habe alle Einstellungen dokumentiert und mehrfach kontrolliert, finde aber keinen Fehler. Wer kann helfen? Wie kann Outlook2016 sich auf den neuen Servernamen verbinden?
    Viele Grüße
    Heiner

  18. Hallo beisammen,
    Ich hatte kürzlich mein Zertifikat über StartSSL bezogen und war eigentlich recht glücklich damit. Alle Systeme (Outlook, IOS, …) funktionierten wunderbar. Heute morgen habe ich meine Apple-Devices auf das neue IOS 10.2 aktualisiert und die Synchronisation funktionierte nicht mehr. Es sieht wohl so aus, als ob Apple die Root-CA, die von StartSSL genutzt wird nicht mehr implementiert hat. Ich habe dann auf dem iPhone versucht, die Zertifikate manuell zu installieren – leider ohne Erfolg. Schade…
    Grüße Andi

  19. Hi Andi,
    Apple hat STartSSL aus der Liste der vertrauenswürdigen CAs genommen (Es gab Sicherheitsprobleme mit der CA).
    Gruß, Frank

  20. @Meik, @Heiner, @Frank

    Ich hatte das gleiche Bild nachdem ich meinen Exchange 2010 mit einem neuen Zertifikat versorgt hatte. Da ich gleichzeitig am Verteilen von Office 2016 war kam sehr schnell die Idee die Frank schon vorschlug – Outlook Profil löschen und neu anlegen. Denn bei mir hatten alle Office 2016 User die ich vor dem Zertifikatswechsel installiert hatte das Problem – alle Installationen nach dem Zertifikatwechsel liefen fehlerfrei und Outlook meckerte nicht …

    Gruß
    Peter

  21. Hallo Frank, danke für die Hilfe! Kann ich Dir die autodiscover XML über dieses Formular zuschicken, oder besser per E-Mail?
    Viele Grüße
    Heiner

  22. Hi,
    du kannst auch die Zone anlegen und in der Zone die entsprechenden Einträge, dann musst du aber auch daran denken die öffentlichen Einträge entsprechend zu pflegen (WWW).
    Gruß, Frank

  23. Hallo Frank.

    Super Erklärung danke dafür.
    Ich hab eine Frage,
    bei dem zertifikat WMSVC welcher Dienst muss da zugewiesen sein?
    Bei mir steht nach einem update da nichts mehr ausgewählt drinn.
    Ich denke das ist so nicht richtig.

    Vielen Dank für deine Antwort

  24. Hi Chris,
    der WMSVC ist ein IIS Dienst (Web Management Service) und gehört nicht zu Exchange, daher wird diesem Zertifikat auch kein Exchange Dienst zugewiesen. Das Zertifikat wird nur vom Web Management Service benutzt.
    Gruß, Frank

  25. Hallo Frank,

    ich habe vor ein paar Tagen einen SBS 2011 auf Exchange 2013 migriert. Wir haben allerdings ein Wildcard Zertifikat was ich dann in den Exchange eingebunden habe. Es funktioniert auch soweit alles bis auf Passwortabfragen die hin und wieder im Outlook auftauchen (auch von extern). DNS Einträge stehen alle. Bei einem Kollegen taucht dann beim Start von Outlook 2013 die Meldung auf das der Name auf dem Zertifikat nicht übereinstimmen würde. Klickt man auf das Zertifikat zeigt er „Domain.de“ an anstatt „*.Domain.de“. Bei einem anderen der Outlook 2016 benutzt kann das Konto gar nicht angebunden werden. Es erscheint immer eine Kennwortabfrage aber keine Zertifikatsfehlermeldung.

    Die Testexchangeconnectivity im Autodiscover sowie im Outlook Modus laufen beide ohne jeglichen Fehler durch.
    Im moment haben wir mehr Probleme mit der Anbindung intern als von Extern.

    Vielleicht hast du ja den Masterplan :-) Bin zu allen Schandtaten bereit.

    Gruß,
    Olli

  26. Hi Olli,
    wurden die internen URLs entsprechend gleich mit den externen URLs konfiguriert und sind diese auch intern via DNS auflösbar?
    Gruß,
    Frank

  27. Hi Frank,

    ja alles vorhanden und auflösbar. Ich bin jetzt schon hingegangen und habe im Outlook Anywhere mal auf NTLM umgestellt. Bei manchen brachte das eine Verbesserung bei anderen wiederum nicht.

    autodiscover.domain.de als Zone vorhanden zeigt auf den Exchange und ist intern sowie extern wunderbar auflösbar.
    remote.domain.de Zone vorhanden zeigt auf den Exchange und ist ebenfalls auflösbar.

    Egal von welchem Server DNS funktioniert einwandfrei.

    Viele Grüße
    Olli

  28. Hallo Frank, Peter und Heiner,

    da ich jetzt endlich mal Zeit hatte mich mit dem Problem des Zertifikatsfehler auseinander zusetzen, ist mir folgendes aufgefallen. Bei Neuinstallation von Outlook 2016 gibt es keine Warnung. Bei einigen Clients hat es auch ausgereicht die ost Datei zu löschen und diese neu erstellen zulassen. Leider funktioniert das nicht bei jedem Client.

    Der Fehler scheint von den Exchange-Empfangsconnectoren zu stammen. Dort steht der FQDN für alle Empfangsconnectoren immer noch auf dem internen Namen (z.B. Exchange.domain.local).

    Vielleicht habt ihr ja eine Idee.

    Viele Grüße
    Maik

    Meine Fragen dazu:
    Kann ich diese einfach auf mail.domain.de ändern? Wird dadurch die Funktionalität des Exchange Servers in irgendeiner Weise beeinflusst? Oder sollte ich ein selbst erstelltes Zertifikat für die Empfangsconnectoren erstellen?

  29. Hi erstmal! „Eigentlich“ genau was ich gesucht habe, jedoch habe ich nach der Konfiguration ein Problem…
    Owa / Activesync funktioniert, jedoch können sich clients mit Outlook 2010 nach Änderung der virtuellen Verzeichnisse nicht mehr anmelden! (Alle Schritte nochmal kontrolliert, keine Änderung)
    Eckdaten: DC: Server2016 (DNS/AD), Exch: Server2016 / 2016 (Exchange, IIS)

    Bereits eingerichtete Profile zeigen einige Minuten den Verbindungsversuch, dann verabschiedet sich Outlook. Mein Hintergedanke war also: Alte Verbidungsinfos stecken noch im Profil. Neues Profil angelegt: Zum Schluss erscheinen die 3 Positionen zum Abschluss und bei „Am Exchange anmelden“ bleibt die Konfig stehen und hängt sich auf.

    Nach dem Reset der Virtuellen Verzeichnisse ging es jetzt zum Glück wieder, aber durch bin ich mit dem Thema noch nicht…

  30. @Frank, @Maik
    Hallo,
    der unsäglichen MAPI Virtual Directory Bug war auch bei mir Ursache allem Übels. Frank sollte vielleicht im Beitrag eine deutliche Warnung setzen, dass nach dem Anpassen der URLs über EAC die Authentifizierung zu kontrollieren ist oder besser gleich die EMS einsetzen. Danke an alle.
    Viele Grüße
    Heiner

  31. Hallo Frank,

    sollte in der Anleitung nicht noch TLS für SMTP erwähnt werden. Es wird hier (vermutlich) davon ausgegangen, dass der MX auch auf mail.frankysweb.de lautet.
    Trotzdem würde STARTTLS für Port 587 (Client-Connector) nicht funktionieren (Zwertifikatwarnung), weil das neue Zertifikat dem Client-Connector noch explizit per set-receiveconnector -tlscertificatename zugewiesen werden muss.

  32. Hallo

    ja wirklich tolle Anleitung. Für MAPI over HTTP musste ich aber noch einen weiteren Befehl hinzufügen

    Set-MapiVirtualDirectory -Identity „ContosoMail\mapi (Default Web Site)“ -ExternalUrl https://contoso.com/mapi -IISAuthenticationMethods NTLM,Negotiate

  33. Hallo Frank

    Ich habe die Anleitung https://www.frankysweb.de/exchange-2016-die-basiskonfiguration/ und danach diese Anleitung durch gearbeitet bis zu DNS. Bei dieser Anleitung beim Thema DNS (Provider) steh ich nun jedoch etwas auf dem Schlauch. Zuerst habe ich keine Fixe IP somit habe ich beim Provider jeweils CNAMES eintragen lassen, anstelle der A Records, welche auf meinen DYNDNS Namen verweisen, ich hoffe dies ist auch korrekt. Aber ich habe bei der bestehenden Konfiguration gesehen, dass es noch MX Einträge gibt, welche momentan zum Provider verweisen. Müsste ich hier nun nicht auch noch einen MX Eintrag erstellen? Würde dieser auf mail.xyz.de verweisen?

    Grüsse & Dank
    Simon

  34. Hallo Simon,

    wenn du keine feste IP hast und den cname gesetzt hast kannst den mx auf den cname zeigen lassen.

    Zum versenden verwende aber bitte unbedingt einen Smarthost. Thema Spam und dynamischer adresspool beim Provider.

    Viele Grüße
    Olli

  35. Hallo @ll, gestern hatte ich Besuch: Der Fehler: NS_ERROR_NET_INADEQUATE_SECURITY zeigte sich im Firefox, wenn ich auf meinem frisch installierten Exchange 2016 CU5 mit eigenen AD-Zertifiakten per OWA zugreifen wollte.
    OK – Firefox mag kein SHA1 – macht ja Sinn..
    Also Zertifizierungsstelle auf SHA-256 umgestellt: certutil -setreg ca\csp\CNGHashAlgorithm SHA256 – neues Zertifikat gleiches Problem
    Hier https://www.nartac.com/Products/IISCrypto habe ich „best practice“ ausgeführt – nun waren die Zertifikate schön – Firefox zufrieden – aber nach der Anmeldung gab es eine weiße Seite mit dem auth.owa – Problem.
    Der Dienst: Microsoft Exchange-Benachrichtigungsbroker war es nicht – der ist immer nach einigen Sekunden down. Nach gefühlt unendlich langer Fehlersuche, habe ich ein Backup der System-Partition zurück gespielt. VHDX-Datei getauscht. Der Stand vom Vormittag war wieder da, dann die gleichen Schritte noch mal ausgeführt und schont konnten alle Browser (die das passende CA hatten) auf das OWA zugreifen… Es ist immer wieder schön auch während der Installation ein Backup zu haben :-) Viele Grüße aus Berlin Jens

  36. Hallo Franky,
    wirklich tolle Anleitung. :-)

    Ich hab hier Exchange 2010 laufen und bin aktuell dabei deine Anleitung durchzuarbeiten, da ich nun auch ein externes Zertifikat einsetzen möchte.

    Was mir allerdings fehlt sind in Exchange 2010 die MAPI & die EWS ìntern/extern URL, wo finde ich diese?

    Danke.

  37. Hi Mike,

    MAPIoverHTTP wird nicht von Exchange 2010 unterstützt. EWS lässt sich per Shell konfigurieren: get/set-webservicesvirtualdirectory

    Gruß, Frank

  38. Hallo Frank,

    Danke für deine Hilfe und das HowTo, läuft einwandfrei jetzt endlich auch ohne externen Zertifikat Fehler :)

    gruß Mike

  39. Hallo Frank,

    ich möchte auch einmal ein herzliches Dankeschön hier lassen! Deine Tutorials usw. helfen mir sehr, bzw. haben mir auch sehr geholfen einen Windows Server 2016 mit Exchange einzurichten. Gerade die Zertifikate waren etwas schwieriger, mit deiner guten Erklärung jedoch ganz einfach und man hat es auch verstanden für Folgeprojekte.

    Ich hoffe du machst noch weiter! Einiges gibt es sicher noch zu lernen :-)

    Danke und schöne Grüße!

  40. Vielen Dank für das Lob, schön zu hören das es weitergeholfen hat. Ich betreibe diese Seite ja nun schon ein paar Jahre und möchte das auch noch ein paar weitere Jahre machen :-)
    Ich lerne ja auch jeden Tag etwas dazu :)

  41. @ Heiner @Maik, @Frank, Hallo,
    habe jetzt das gleiche Problem wie ihr:
    Schritt für Schritt nach Anleitung von Frank umgesetzt (auf Exchange2016 aktuelle CU mit Outlook2016 u.2013-Clients),
    alles funktioniert wie erwartet,außer Outlook -> Zertifikatsfehler! Outlook bekommt immer noch den
    alten internen Servernamen „ex1.meinedomäne.de“ präsentiert wo hingegen das neue Zertifikat auf „mail.meinedomäne.de“ lautet. Alle URLs intern+extern(owa,OAB,Microsoft-Server ActiveSync, mapi, EWS, ec, Outlook Anywhere) auf „mail.meinedomäne.de“ sowie autodiscover intern auf „autodiscover.meinedomäne.de“ angepasst. Habe alle Einstellungen dokumentiert und mehrfach kontrolliert, finde aber keinen Fehler. Wer kann helfen? Wie kann Outlook sich auf den neuen Servernamen verbinden?
    Viele Grüße
    Marcus

  42. es ist nicht unbedingt ein Zertifikatsfehler aber irgendwo ist noch ein Wurm drin.
    Ich bekomme den sicherheitshinweis
    Zertifikat gültig, Dauer gültig aber dann –
    Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Webseite überein.
    Dann erscheint oben der „falsche FQDN“ des Servers und zwar mit seinem internen Servernamen und nicht mit exchange.intern.domäne.de auf dem zertifikat habe ich aber stehen outlook.domäne.de bzw. autodiscover.domäne.de
    Wie bekomme ich das korrigiert ? Bis ich das neue Zertifikat installiert hatte war ja alles OK :) Nun ist es halt ein echtes.

  43. Hi Marcus,

    leider kann ich dir nicht genau sagen wo der Fehler bei mir lag, aber ich nehme an das der IIS was damit zutun hat. Schlussendlich habe ich ein IIS-Reset auf dem Server gemacht und Ruhe war.
    Heute habe ich keine Zertifikatswahrungen mehr. Vorher habe ich viele Möglichkeiten ausprobiert, welche manchmal auch zum Erfolge geführt haben.
    Lokalen Outlook Cache löschen und Outlook Neuinstallation haben meist die Warnungen verschwinden lassen. Komischerweise nicht bei allen Usern.
    Bei Usern mit zwei oder mehr Postfächer hat es meist nicht geholfen.
    Aber seit dem IIS Reset (Cache leeren) ist alles wieder in Ordnung.

    Viele Grüße
    Maik

  44. so Exchange und DC neu gestartet. Leider keine Veränderung.
    Was aber auch total seltsam ist, bei einigen Benutztern klappt die Anmeldung über die Outlook App für IOS bei anderen nicht ?? Gibt es eine Beschränkung der Postfachgröße Bei der App ? Die beiden Benutzer, die es zur Zeit nicht könne waren vorher in der Gruppe Domänenadmin, da habe ich Sie rausgenommen, da ich glaube irgendwo mal gelesen zu haben, das es deshalb nicht geht, aber auch das brachte bisher keine Veränderung.
    Jemand ein Paar Ideen für mich ? Danke

  45. Sorry wenn ich euch hier so zuspamme, aber Problem ist immer noch nicht gelöst, ganz im Gegenteil.
    Ich habe etwas an den Zertifikaten im Manager geändert. Seitdem verbindet sich auch intern kein Outlook mehr. normalerweise kein Problem hatte ja alle Zertifikate gesichert und die Einstellungen dokumentiert. Nun aber das Problem ich kann mich zwar in OWA und auch im ECP anmelden, bekomme dann aber nur eine blanke Seite angezeigt.
    Wäre Super wenn mir jemand einen Tip geben könnte wo der Fehler liegt.
    Ansonsten werde ich morgen dann wohl alles neu installieren müssen

  46. Update Echange Konsole geht wieder, Im ISS dem Port 444 ein SSL Zertifikat zugewiesen dann kommt man wieder rein :) leider versnedet der Exchange im Moment keine Mails an extern, da muss ich jetzt mal nachsehen

  47. nochmals Update und Gute Nacht,
    bis auf den Zertifikatsfehler geht jetzt wieder alles :) also ich stehe wieder am Anfang.
    Wenn es gar nicht anders geht kommt halt ein Wildcard Zertifikat, kostet zwar wieder etwas mehr aber ist wahrscheinlich Stressfreier

  48. Mach mal ein neues Zertifikat selbst. Auch mit neuer Vorlage. Hatte ich mal bei einem Kunden, dass das Zertifikat nach Installation immer ein paar Stunden ging, dann blank nach Anmeldung. Habe nie rausgefunden, was das Problem war, aber lag an der Vorlage in der Zertifizierungsstelle.

  49. Hallo Zusammen,
    erst mal großes Lob an die super Klasse Anleitung von Frank. Habe mit dieser Anleitung entsprechend alles konfiguriert auf meinem Exchange 2016. Es läuft auch alles soweit ordentlich. Habe nur das Problem, dass ich mit dem Firefox nicht auf das OWA zugreifen kann. Es kommt immer die Fehlermeldung NS_ERROR_NET_INADEQUATE_SECURITY. Wo muss noch eine Einstellung gemacht werden, dass OWA auch unter Firefox und nicht nur unter IE und Edge funktioniert?
    Vielleicht weiß jemand Rat. Danke!
    Gruß
    Markus

  50. Hi Frank, danke für den Hinweis und den Link. Das hat mir geholfen.
    Habe aber leider noch ein Problem Lokal im Outlook. Trotz der Konfiguration deiner Anleitung kommt jetzt
    noch der Fehler „Der name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein“, obwohl der korrekte Name im Zertifikat steht. Er syncronisiert die Mails auch, alles scheint zu funktionieren, aber die Meldung kommt nach ca. 1 Minute nach öffnen des Outlooks. Man muss mit Ja bestätigen und dann kommt diese erst wieder, wenn der Outlook geschlossen wird und neu geöffnet wird.
    Hast du mir Hier einen Tipp, an was das noch liegen kann? Ich habe ein Zertifikat von GeoTrust.
    Danke
    Gruß Markus

  51. Hi.
    Leider kommt bei mir der Fehler „CSR format content parse error, please generate a new one“ wenn ich die ANforderung in das Feld kopiere. Habe es auch schon mehrmals neu erstellt.
    Was mache ich denn dort falsch?
    Danke dir.

    VG,
    Jens

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.