Exchange 2016: Zertifikate konfigurieren (Teil 1)

Mittlerweile erreichen mich täglich Mails mit Fragen zu Zertifikaten und/oder Outlook Anywhere. Wobei auch die Fragen zu Outlook Anywhere meistens ebenfalls auf die Zertifikate zurückzuführen sind. In den meisten Fällen enden die Mails einem Satz ähnlich wie diesem:

Zertifikate sind für mich ein rotes Tuch!

Der Satz stammt aus einer Mail die ich heute erhalten habe. Da wie schon erwähnt diese Mails langsam überhand nehmen, versuche ich mal ein bisschen Licht ins Dunkel zu bringen. Dazu soll dieser Artikel dienen. Dieser Artikel ist bewusst möglichst ausführlich und einfach gehalten und richtet sich an Einsteiger in diesem Thema. Ich hoffe es hilft einigen Leuten.

Noch eine Bitte vorab: Wenn etwas unklar ist, bitte einen Kommentar hinterlassen, damit ich den Artikel entsprechend aktualisieren kann.

Hintergrund: Wie funktionieren Zertifikate

Keine Angst, ich will gar nicht tief ins Detail gehen, sondern nur ganz oberflächlich erklären wie ein Zertifikat funktioniert. Als Beispiel nehmen wir mal einen Personalausweis. Ein Personalausweis enthält Daten zu meiner Person um diese zu identifizieren, also beispielsweise den Namen, ein Foto und eine Unterschrift. Ebenfalls wird ein Personalausweis von einem Land (oder einer Behörde) ausgestellt.

Beispiel Ausweis

Wenn ich die Identität von jemanden mit dem ich gerade rede feststellen möchte, kann ich mir also seinen Personalausweis zeigen lassen und kann die Daten auf dem Ausweis (Foto und Unterschrift) mit meinem Gesprächspartner vergleichen. Stimmen die Merkmale überein, handelt es sich wahrscheinlich um die entsprechende Person. Allerdings muss ich dazu jemandem Vertrauen. Erstens muss ich meinem Gesprächspartner vertrauen, das er den Ausweis nicht gefälscht hat und ich muss dem Staat oder der Behörde vertrauen, dass die Identität meines Gesprächspartners auch wirklich geprüft wurde und somit der Ausweis an sich vertrauenswürdig ist. Mein Gesprächspartner könnte mich ja schließlich auch einen Zettel mit Foto und Unterschrift zeigen, den er eben selbst gemalt hat. Als Ausweis akzeptiere ich das natürlich nicht.

Beispiel Zertifikate

Angenommen ich bin nun keine Person mehr, sondern ein PC der mit einem Server sprechen möchte. Ich als PC bekomme vom Server den Ausweis (Zertifikat) gezeigt. Die Daten auf dem Zertifikat kann ich nun prüfen:

• Welcher Name steht auf dem Zertifikat?
• Wer hat es ausgestellt?
• Sehe ich das Zertifikat als gültig an?

Etwas genauer gesagt: Eine Zertifizierungsstelle (Behörde/Land) stellt ein Zertifikat aus, dieser Zertifizierungsstelle muss ich vertrauen, dass Sie ihre Arbeit gewissenhaft erledigt und die Identität entsprechend geprüft hat. Ein selbst ausgestelltes Zertifikat ähnelt dem selbst gemalten Ausweis. Wenn ich mir als PC in einem der Punkte nicht sicher bin, gebe ich eine entsprechende Warnung aus. Auf die Folgen kommen wir später zu sprechen.

Das soll es auch schon zum Hintergrund gewesen sein. Natürlich ist das Thema Zertifikate etwas komplexer, aber für diesen Artikel soll es erst einmal reichen. Verschlüsselung, Sperrlisten, Algorithmen  und was es noch alles gibt, interessiert hier erst einmal nicht weiter.

Hintergrund: Exchange 2016 und Zertifikate

Ein Exchange Server bietet mehrere Dienste an, die mit Zertifikaten konfiguriert werden können/müssen. Ein Dienst stellt dabei, um beim Beispiel zu bleiben, einen Gesprächspartner dar. Im wesentlichen sind es die folgenden Dienste, die ein Zertifikat (Stichwort Ausweis) benötigen:

• IIS
• SMTP
• IMAP
• POP

UC lassen wir an dieser Stelle mal außen vor. Jeder dieser Dienste (Gesprächspartner) KANN ein eigenes Zertifikat (Ausweis) erhalten, MUSS aber nicht. Ein Zertifikat kann mehreren Diensten zugeordnet sein, ähnlich wie eine Gesprächspartner der mehrere Sprachen spricht, aber nur einen Ausweis hat.

Eine Besonderheit ist allerdings, dass ein Exchange Server mehrere Namen hat, die auf dem Zertifikat vorhanden sein müssen. Dies ist vergleichbar mit einem zweiten Vornamen auf dem Ausweis.

Beispielumgebung

Um die Sache mit den Ausweisen, äh… Zertifikaten etwas deutlicher zu machen, habe ich eine Beispielumgebung installiert.

Allgemeine Beschreibung

Im wesentlichen besteht die Umgebung aus drei Abschnitten:

• Einem Benutzer im Home Office (blau)
• Das Internet mit einem Hoster für das Unternehmen (rot)
• Das Unternehmen welches den Exchange Server bereitstellt (grün)

Der Benutzer im Home Office hat nur einen normalen Internetanschluss, kein VPN oder sonstiges, nur einen PC mit Outlook.

Das Unternehmen stellt die Exchange Infrastruktur bereit, verfügt also über einen Domain Controller und einen Exchange Server. Ob das Unternehmen nun Domain Controller und Exchange Server auf einer VM oder physikalisch betreibt oder ob es ein Server/VM oder getrennte Server sind, spielt in diesem Beispiel keine Rolle. Das Unternehmen hat ebenfalls Benutzer die auf Exchange zugreifen innerhalb des eigenen LANs.

Das Unternehmen hat einen Hoster im Internet damit beauftragt, eine Domain für das Unternehmen zu hosten.

Die Details zum Unternehmen

Der Name dieses fiktiven Unternehmens ist „FrankysWeb“. FrankysWeb hat einen Internetanschluss mit fester IP-Adresse und ein Active Directory welches auf den Namen „frankysweb.local“ hört. Die E-Mail Adressen des Unternehmen enden auf frankysweb.de. Intern sieht das Netzwerk also in etwa so aus:

• Name des Active Directory: frankysweb.local
• Name des Domain Controllers: dc1.frankysweb.local
• Name des Exchange Servers: EX1.frankysweb.local
• E-Mail Adresse des internen Benutzers: frank@frankysweb.de
• Benutzername: frank@frankysweb.local
• Feste externe IP-Adresse: 81.169.145.159

Der Benutzer Frank nutzt ein Notebook und ist sowohl intern im Unternehmen als auch im Home Office tätig.

Die Details zum Hoster im Internet

Das fiktive Unternehmen FrankysWeb hat den Hoster Strato damit beauftragt die Domain frankysweb.de zu hosten.

Strato hostet ebenfalls die Website des Unternehmens und betreibt die DNS-Server für frankysweb.de

Die Details zum Home Office

Das Home Office wird gern vom Benutzer Frank genutzt, hier ist nur ein normaler Internetanschluss, ohne feste IP, oder sonstige Konfiguration. Es wird kein VPN genutzt, aber Mails sollen im Home Office bearbeitet werden können.

Frank möchte dazu Outlook Anywhere vom PC aus benutzen und ActiveSync vom Smartphone. Wenn es schnell gehen muss, nutzt er auch Outlook Web Access. Frank möchte auf keinen Fall einen dieser Fehler sehen:

Und auch die folgenden Fehler möchte Frank nicht zu Gesicht bekommen:

Vorkonfiguration der Beispielumgebung

Bisher sind nur der Domain Controller für die Domain frankysweb.local und der Exchange 2016 Server installiert. Auf dem Exchange Server gibt es nur eine akzeptierte Domain, sowie das Postfach für Frank und eine Adressrichtlinie, die dem Postfach für Frank die E-Mail Adresse frank@frankysweb.de zuweist. Mehr ist bisher nicht konfiguriert worden. Der Vollständigkeit halber hier einmal die Screenshots:

Die Beispielumgebung ist also mehr oder weniger eine grüne Wiese. So oder so ähnlich werden aber die meisten Umgebungen in den Mails geschildert, in denen es immer wieder Probleme mit Zertifikaten gibt:

• Active Directory Domain Name endet auf .local oder ähnlichem
• Es gibt einen Domain Controller und einen Exchange Server bzw. Exchange und Domain Controller laufen auf einem Server (ungünstig, aber für diesen Artikel nicht von Bedeutung)
• Ein Internet Anschluss mit fester IP ist vorhanden
• Ein Hoster (Strato, 1und1 HostEurope, etc) hosten die Mail Domain

Die Anforderungen sind dann schnell definiert:

• Outlook Anywhere soll/muss funktionieren
• Keine Zertifikatswarnungen mehr

Dieser Artikel soll dabei helfen diese Anforderungen umzusetzen, und gilt für Exchange 2013 und Exchange 2016 und entsprechend unterstützten Outlook Versionen.

Exchange in der Standardkonfiguration

Während der Exchange Installation wird bereits ein Zertifikat installiert und den Exchange Diensten zugewiesen. Dabei handelt es sich um ein Selbstsigniertes Zertifikat, wie diesem aus der Beispielumgebung:

Das Standard Zertifikat der Beispielumgebung, welches bei der Installation geniert wird, schaut im Browser dann wie folgt:

Der Exchange Server hört auf den Namen EX1 und hat sich daher ein Zertifikat mit dem Namen EX1 selbst ausgestellt, dies wird im Screenshot oben deutlich (Ausgestellt für EX1, Ausgestellt von EX1). Um bei dem Ausweisbeispiel zu bleiben: Dies ist der handgemalte Ausweis, kein offizielles Dokument einer Behörde, sondern eher vergleichbar mit einer Visitenkarte. Auf Visitenkarten kann jeglicher Unsinn stehen, niemand kann es prüfen, ob es auch stimmt.

Eine kleiner Besonderheit wird in diesem Screenshot sichtbar:

Das Standard Zertifikat enthält bereits zwei Namen (DNS-Name), einmal den Shortname (UNC-Name) und einmal den FQDN. Bei den Standard Zertifikat handelt es sich somit schon um ein SAN-Zertifikat (Subject Alternate Name). SAN hat in diesem Fall nichts mit Storage Netzwerken zu tun, sondern bezeichnet einen Zertifikatstyp. Hier werden mehrere Namen auf einem Zertifikat hinterlegt. Im Screenshot oben sind das die Namen EX1 und EX1.frankysweb.local. Wieder zurück zu den Ausweisen: Hier wurde Vorname und zweiter Vorname angegeben, oder Vor- und Zuname, aber das ist Haarspalterei.

Ein Client, der sich mit diesem Exchange Server verbindet wird die folgende Fehlermeldung im Browser bekommen:

Ob Internet Explorer, Edge, Chrome, Firefox ist erst einmal egal, die Fehlermeldung sieht überall ähnlich aus:

Warum der Fehler auftritt ist schnell erklärt: Der selbstgemalte Ausweis ist Schuld, zwar steht auf dem Ausweis ein Name, aber niemand hat überprüft und verifiziert, dass dieser Name auch wirklich stimmt. Vereinfacht erklärt: Bei unserer Ausweiskontrolle versucht sich hier jemand gerade mit einer Visitenkarte auszuweisen.

Jetzt stellt sich natürlich die Frage, wer denn überhaupt berechtigt ist, gültige Zertifikate (Ausweise) auszustellen?

Die Zertifizierungsstelle (Beispiel: Behörde/Land)

Damit ein Zertifikat als gültig angesehen wird, muss also nicht nur der Name auf dem Zertifikat stimmen, sondern es muss auch von einer vertrauenswürdigen Stelle ausgestellt worden sein. Eine Visitenkarte reicht also nicht, ein Personalausweis, der von einem Land oder entsprechender Behörde ausgestellt wurde, ist viel vertrauenswürdiger. Die Zertifizierungsstellen übernehmend das Ausstellen der Zertifikate und sind in diesem Beispiel vergleichbar mit einem Land oder Behörde. Im folgenden Beispiel hat die Zertifizierungsstelle (CA) Wosign (Roter Kasten) ein Zertifikat für mail.frankysweb.de (Blauer Kasten) ausgestellt:

In den Screenshot oben ist auch zu sehen, dass Zertifizierungsstellen häufig mehrstufig aufgebaut sind. Die Stammzertifizierungsstelle (Root-CA, im Beispiel das Land) hat eine Zwischenzertifizierungsstelle (Sub-CA, im Beispiel Behörde) signiert, damit die Zwischenzertifizierungsstelle für den Server mail.frankysweb.de (im Beispiel die Person) ein Zertifikat ausstellen kann. Da sich das Zertifikat der Stammzertifizierungsstelle im Windows Zertifikatsspeicher befindet, werden entsprechende Zertifikat als vertrauenswürdig anerkannt, sofern der Name stimmt und das Zertifikat nicht abgelaufen ist.

Wie schon erwähnt befinden sich die Stammzertifizierungsstellenzertifikate im Windows Zertifikatsspeicher, in diesem Speicher befinden sich eine ganze Reihe offizieller Zertifizierungsstellen, die alle ein Prüfungsverfahren durchlaufen haben, um sicherzustellen, dass nur berechtigte Inhaber ein Zertifikat ausgestellt bekommen. Im folgenden Beispiel findet sich das Zertifikat für WoSign:

Die meisten Windows Programme greifen auf den Windows Zertifikatsspeicher zurück um Zertifikate zu prüfen. Eine bekannte Ausnahme bildet hier der Browser Firefox. Firefox bringt seine eigene Zertifikatsverwaltung mit.

Überlegungen zur Exchange Konfiguration

Wie bereits oben beschrieben, reicht das Zertifikat der Standard Exchange Konfiguration nicht aus und muss ausgetauscht werden. Da auf einem Zertifikat aber DNS-Namen (wie Namen auf einem Ausweis) angegeben werden müssen, muss zunächst einmal überlegt werden, über welche DNS-Namen und Protokolle die verschiedenen Programme und Geräte auf den Exchange Server zugreifen werden. In kleinen Umgebungen ist diese Planung recht schnell erledigt, da sich nahezu alles über einen einzelnen DNS-Namen realisieren lässt, Autodiscover bildet allerdings eine Ausnahme: Die folgende Tabelle stellt einmal die Standardkonfiguration dar:

Dienst / Protokoll	DNS-Name
OWA (Interne URL)	https://ex1.frankysweb.local/owa
OWA (externe URL)	https://ex1.frankysweb.local/owa
OAB (interne URL)	https://ex1.frankysweb.local/OAB
OAB (externe URL)	(leer)
ActiveSync (interne URL)	https://ex1.frankysweb.local/Microsoft-Server-ActiveSync
ActiveSync (externe URL)	(leer)
MAPI (interne URL)	https://ex1.frankysweb.local/mapi
MAPI (externe URL)	(leer)
EWS (interne URL)	https://ex1.frankysweb.local/EWS/Exchange.asmx
EWS (externe URL)	(leer)
ECP (interne URL)	https://ex1.frankysweb.local/ecp
ECP (externe URL)	(leer)
Outlook Anywhere (Intern)	ex1.frankysweb.local
Outlook Anywhere (extern)	(leer)
Autodiscover (Intern)	https://ex1.frankysweb.local/Autodiscover/Autodiscover.xml

In der Standardkonfiguration enthalten also alle Zugriffspunkte den internen Servernamen und die externen sind leer. Mit internen Servernamen kann der Benutzer im Home Office natürlich nichts anfangen, wenn er keine VPN Verbindung hat. Weiterhin gilt für Exchange Server 2013 und Exchange Server 2016 die Best Practise interne und externe Zugriffsnamen gleich zu halten.

Wenn es also nur einen Exchange Server im Unternehmen gibt, dann wird dieser Server von internen Benutzern, sowie von externen Benutzern angesprochen werden.

Da wir in diesem Fall ja glücklicher Besitzer einer öffentlichen Domain bei einem Hoster sind, können wir mittels Subdomain einen öffentlichen Namen definieren. Für die Domain frankysweb.de könnte der Exchange Zugriff also über die folgende Subdomain erfolgen: mail.frankysweb.de (Alternativ irgendein anderen Namen den sich die Benutzer gut merken können).

Eine kleine Ausnahme bildet Autodiscover, der Autodiscover Eintrag sollte immer unter autodiscover.domain.tld veröffentlicht werden, die Veröffentlichung von autodiscover unter dem entsprechenden Namen verhindert eine Warnung die einmalig von Outlook angezeigt wird. Für die Domain frankysweb.de wäre der Autodiscover Eintrag also autodiscover.frankysweb.de.

Darauf würde sich unter der Berücksichtigung der Best Practise (interne und externe Namen gleich, keine internen Namen auf öffentlichen Zertifikaten, Autodiscover mit separaten Namen) die folgende Konfiguration ergeben:

Dienst / Protokoll	DNS-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

Aus dieser Konfiguration ergibt nun das Zertifikat.

Überlegungen für das Zertifikat

Aus der Konfiguration oben ergeben sich schon die Anforderungen für das Zertifikat. Auf einem Zertifikat werden nur die FQDNs (DNS-Namen) angegeben, keine URLs! Daher wird auch ntur ein Zertifikat mit genau zwei Namen benötigt:

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

In diesem Fall wird also ein SAN-Zertifikat (Subject Alternate Name) benötigt, welches die oben angegebenen Namen enthält. Mehr nicht.

Das Zertifikat muss aber von einer Zertifizierungsstelle ausgestellt werden, wenn es als gültig anerkannt werden soll. Es besteht die Möglichkeit selbst eine Zertifizierungsstelle zu betreiben, allerdings lohnt meist der Aufwand in kleinen Umgebungen nicht, denn ein entsprechendes Zertifikat gibt es kostenlos oder auch gegen geringe Gebühr. Hinzu kommt: Eine eigne Zertifizierungsstelle die auf einem Windows Server installiert wird, ist erst einmal nur innerhalb des Active Directory vertrauenswürdig. Ein Smartphone oder ein Client der nicht Mitglied des Active Directory ist, wird das Zertifikat nicht als vertrauenswürdig ansehen und wieder mit den bekannten Fehlern reagieren.

Meine Empfehlung daher: Entsprechendes Zertifikat von einer offiziellen Zertifizierungsstelle beziehen.

Konfiguration Exchange Server

Da dieser Artikel schon recht lang geworden ist, wird die Konfiguration im nächsten Artikel behandelt. Sobald der Artikel online ist, werde ich ihn hier verlinken.

Update: Teil 2 ist inzwischen ebenfalls verfügbar.