Exchange Server – Zertifikate

Erstellen und Binden der Exchange Server Zertifikate…

<<< Konfiguration Client Access | Übersicht Action Plan | Exchange Datenbanken >>>

Kurzversion für Forgeschrittene:

New-ExchangeCertificate –Server mailer –GenerateRequest –FriendlyName mail.contoso.com –PrivateKeyExportable $true –SubjectName "c=COUNTRY, s=STATE, l=LOCATION, o=Organizationname, ou=OrganizationUnit, cn=mail.contoso.com" –DomainName  mail.contoso.com,autodiscover.contoso.com,mail01.contoso.net –RequestFile "C:\tmp\certreq.req"

Allgemeines

Der Exchange Server verwendet Zertifikate, um seine Services verschlüsselt bereitstellen zu können. Hierbei unterscheidet man 5 Dienste, welche man mit einem Zertifikat schützen sollte.

1. Internet Information Services (IIS)
   Dies ist der Dienst, welcher die Webservices des Exchange Server „hostet“, wie bspw. OWA, ECP, ActiveSync, etc. Diese Webservices liefern Ihre Webseiten SSL verschlüsselt aus.
2. Simple Mail Transfer Protocol (SMTP)
   Der Mailtransport-Service des Exchange Servers. Dieser verschlüsselt beim Versand und Empfang die Emails mit dem jeweilig anderen Email-Server. Hier kommt StartTLS zum Einsatz, ein Service, welcher ebenfalls ein Zertifikat benötigt.
3. Post Office Protocol Secure (POPS)
   Dieser Client Access Dienst ist standardmäßig deaktiviert, kann aber jederzeit aktiviert werden. Aktiviert man POPS, wird an diesem Service ebenfalls ein Zertifkat für die Client Verbindungen benötigt. POP ohne „S“, also unverschlüsselt, sollte heute nicht mehr implementiert werden!
4. Internet Message Access Protocol Secure (IMAPS)
   Dieser Client Access Dienst ist ebenfalls standardmäßig deaktiviert, kann aber jederzeit aktiviert werden. Aktiviert man IMAPS, wird an diesem Service ebenfalls ein Zertifkat für die Client Verbindungen benötigt. IMAP ohne „S“, also unverschlüsselt, sollte heute nicht mehr implementiert werden!
5. Unified Messaging (UM)
   Auch die Unified Messaging Services (bspw. Skype for Business) verwenden für die Kommunikation mit den entsprechenden Messaging Services Zertifikate.

Zum Glück muss man nicht für jedes Protokoll ein eigenes Zertifikat verwenden, sondern kann bspw. ein sog. SAN (Subject Alternative Name) Zertifikat verwenden, welches alle notwendigen Namen beinhaltet, die beim Zugriff auf den Exchange Server verwendet werden. Sieh dazu auch den Beitrag Konfiguration der virtuellen Verzeichnisse…

Eines vorweg: Ein sog. Wildcard Zertifikat ist am Exchange Server offiziell nicht supportet, da für das SMTP Protokoll eine Zeichenkette in Form des Namens als „Subject“ benötigt wird, hier also kein Wildcard Character unterstützt wird. Also Exchange und Wildcard ist hier eher eine schlechte Lösung.

Ok, zu den Zertifikaten und dem Thema „Self Signed“ vs. „Public Signed“
Dieses Thema verursacht oft Diskussionen, weil ein öffentlich signiertes Zertifkat, welches auch noch mehrere Namen beinhalten soll, regelmäßig Geld kostet, denn man muss ein solches Zertifikat im Regelfall kaufen. So kommt man natürlich schnell zur Frage, ob man ein selbstsigniertes Zertifikat einsetzen sollte, oder ein öffentlich signiertes. Ich empfehle grundsätzlich ein öffentlich signiertes Zertifikat einzusetzen, denn die Impacts für das Thema Mobile Device Access, also ActiveSync, aber auch Outlook Anywhere, also Zugriff auf den Exchange vom WAN, sind gerade für kleinere und mittlere Unternehmen kaum zu händeln. Kommt es dann noch „irgendwann“ zu einer hybriden Bereitstellung und Federation, bspw. wegen eines O365 Onboarding, muss sowieso ein öffentlich signiertes Zertifikat beschafft werden, denn selbstsignierte Zertifikate werden hier nicht wirklich unterstützt.

Zitat von Paul Cunningham: „If you’re tempted to stick with the self-signed certificate, or to try and disable SSL requirements on Exchange services, I strongly recommend you do not do those things.“ (Quelle: Exchange Server 2016 SSL Certificates)

Ja, auch ich habe bereits mit „Let’s Encrypt“ Zertifikaten gearbeitet, meist scheitert diese Variante daran, dass meine Kunden mit der Verlängerung der Zertifikate nach 3 Montane nicht zurecht kamen, ich also wieder ran musste, was am Ende mehr Kosten verursachte als ein SAN (oder auch UCC Zertifikat) über die Laufzeit von bspw. 2 Jahren.

Unter Betrachtung all dieser Punkte setze ich ausschließlich und nur dann selbstsignierte Zertifikate ein, wenn tatsächlich keinerlei Zugriff von extern auf den Exchange Server erfolgt und dies auf kurz oder lang auch nicht geplant ist, oder wenn es sich um reine Laborumgebungen handelt. In diesen Fällen ist darauf zu achten, dass die entsprechende interne Stammzertifizierungsstelle innerhalb der Domain via GPO auf allen Clients als vertrauenswürdig registriert wird. Dies ist mit einem GPO schnell erledigt. (sehr gute Erklärung hier…)

 Vorbereitungen

Alles steht und fällt mit der Definition der sog. Namespaces, also den Namen, die aktuell und künftig für den Zugriff der Clients auf die Collaboration Plattform verwendet werden.
Im Beitrag Exchange Migration – Konfiguration der virtuellen Verzeichnisse habe ich bereits Einiges dazu geschrieben. Ich orientiere mich im weiteren Verlauf an diesen Beispielen.

In diesem Fall handelt es sich um einen sog. Single Namespace, also die Zugriffe erfolgen immer auf ein und denselben Namen, dennoch benötigt man ein SAN Zertifikat.
Warum? Es ist für die Verbindung eines Outlook Client zum Exchange Server (wenn dieser von extern auf den Exchange Server zugreift) mindestens 2 „Namen“ (Subjects) notwendig:

• Als erstes „Subject“ muss der definierte Client Access Name, meist ein Phantasiename wie „mail“, mit angehängter SMTP domain „contoso“ und der zugehörigen Top Level Domain (TLD) „com“ durch das Zertifikat geschützt werden. So ergibt sich für den Client Zugriff zunächst also mail.contoso.com als Eintrag im öffentlichen DNS und „zu schützender“ Name im Zertifikat. (die Maildomain deshalb, weil der Benutzer immer zuerst seine Email-Adresse eingibt, wenn er Outlook das erste Mal startet…)
• Als zweites „Subject“ muss auch der Name autodiscover.maildomain.tld mit einem Zertifikat geschützt sein. Natürlich muss, damit bspw. Outlook Anywhere und die Einrichtung von ActiveSync Devices sauber funktioniert, der Autodiscover Record in der öffentlichen DNS Zone vorhanden sein und auf den lokalen Exchange Server (also dessen Public IP) zeigen. Es ist also in meinem Beispiel-Fall ein DNS Eintrag autodiscover.contoso.com zu setzen. Die lokale Firewall und idealerweiser ein Reverse Proxy, sollten dann die Verbindung zur internen IP des Exchange Server regeln.

Autodiscover selbst habe ich hier etwas genauer beleuchtet…

Namespaces definieren

Nachdem wir das nun alles wissen, müssen also mindestens die „Subjects“

• mail.contoso.com
• autodiscover.contoso.com

im Zertifkat enthalten sein. Für die Koexistenz-Phase von Exchange 2010 / Exchange 2016 muss allerdings auch der Legacy Namespace ins Zertifikat aufgenommen werden, denn die vorhandenen Clients werden sich noch immer auf den alten Server und seinen Namen verbinden, solange die Mailboxen noch nicht auf den neuen Server migriert sind. Dazu erfolgt – nach dem CAS Switch – eine sog. Proxy Weiterleitung vom Exchange Server 2016, auf den alten Exchange 2010. Dieser wiederum antwortet jedoch mit seinem alten Namen (Legacy Namespace), weshalb dieser ebenfalls im Zertifikat enthalten sein muss. In meinem Beispiel heißt dieser mail01.contoso.net. Somit muss mein Zertifikat also die folgenden 3 SAN’s enthalten:

• mail.contoso.com
• autodiscover.contoso.com
• mailer.contoso.net

Im Übrigen handelt es sich bei dieser Kombination nicht mehr um ein klassisches „SAN-Zertifikat“, sondern um ein sog. „Multi-Domain Zertifikat“, da eine abweichende Domain (contoso.net vs. contoso.com) geschützt werden soll. Klassische SAN’s oder auch UCC-Zertifikate schützen dagegen nur Subjects des gleichen Namespace, also mailer.contoso.net, mail.contoso.net, autodiscover.contoso.net.

Zertifikatsrequest erstellen

Einen Zertifikatsrequest kann man natürlich ebenfalls via grafischer Exchange Verwaltungsoberfläche oder via PowerShell erstellen.
Auch hier verwende ich die PowerShell, weils einfach weniger Klicks sind. Dieser Befehl erstellt den Request für die o.g. Subjects:

New-ExchangeCertificate –Server mailer –GenerateRequest –FriendlyName mail.contoso.com –PrivateKeyExportable $true –SubjectName "c=COUNTRY, s=STATE, l=LOCATION, o=Organizationname, ou=OrganizationUnit, cn=mail.contoso.com" –DomainName  mail.contoso.com,autodiscover.contoso.com,mail01.contoso.net –RequestFile "C:\tmp\certreq.req"

Die Parameter:

• • –Server mailer –> Name des Exchange Servers, auf welchem das Zertifikat erstellt werden soll
  • –GenerateRequest –> Erstelle einen Anforderungsdatei
  • –FriendlyName –> Anzeigename des Zertifikats
  • –PrivateKeyExportable $true –> Der private Schlüssel soll exportierbar sein, damit das Zertifikat auch auf einem anderen System (bspw. dem alten Mailserver, Reverse Proxy) importiert werden kann. Um das zu tun, benötigt man den Private Key.
  • –SubjectName –> Angaben zum Zertifikat
  • Die Parameter c, s, l, o, ou sind selbstredend
  • cn –> Der Name des Zertifikats
  • –DomainName –> hier gelistet, durch Komma getrennt, die SAN’s, welche durch das Zertifikat geschützt werden sollen (Achtung, die meisten Zertifikate verursachen Kosten pro SAN!)
  • –RequestFile –> In diesem File wird der Zertifikatsrequest codiert exportiert. Dieses File wird für die Beantragung des Zertifikats benötigt!

Zertifikatsrequest einreichen

Im Normalfall wendet man sich mit der *.req Datei an einen Zertifkatslieferanten, gibt seine Daten ein und hängt das Request-File an. Kurze Zeit später, eventuell nach einer Validierung durch die CA, wird das Zertifikat im PEM Format geliefert.

Sollte man eine interne PKI (Public-Key-Infrastruktur) betreiben, kann man das Zertifikat auch hier einreichen (PKI Webservice muss natürlich installiert sein) und bekommt, sofern das entsprechende Webserver Template aktiviert ist, das Zertifikat direkt ausgestellt.
Dazu ruft man im Browser einfach http://NAMEDERSUBCA/certsrv auf und kopiert den Inhalt des Request in das dafür vorgesehene Feld.

Hier ein Beispiel:

Download des Zertifikats:

Zertifikat importieren

Jetzt, da wir das Zertifkat heruntergeladen oder von der CA erhalten haben, gilt es dieses am Server zu importieren und den Private Key hierbei als exportierbar zu markieren. Dazu verwende ich tatsächlich jetzt mal die Web GUI, denn das ist tatsächlich einfacher. Man muss lediglich die unter Server -> Zertifikate ausstehende Anfordserung abschließen. Dazu einfach den Speicherort und das Zertifikatsfile angeben. Achtung, es wird hier ein UNC Pfad erwartet, also wenn das Zertifikat local auf dem Server liegt, dann bspw. \\localhost\C$\Ordner\Zertifikatsfile.p7b angeben. Anschließend kann man das Zertifikat hier auch jederzeit – incl. Private Key – exportieren.

TLS Namen der Konnektoren anpassen

Im nächsten Schritt wird es etwas PowerShell lastig…
Im Beitrag Exchange Migration – Konfiguration der Konnektoren haben wir die Empfangskonnektoren angelegt. Jetzt gilt es, den TlsCertificateName korrekt zuzuweisen, da es sonst zu Zertifkatsfehlermeldungen und damit fehlerhaften Verbindungen kommt, wenn ein Client oder anderer Server versucht, eine Verbindung mit STartTLS auf den SMTP Empfangskonnektor herzustellen.
Ein Beispiel…
So sieht der Server by Default aus, wenn wir die Abfrage auf die Eigenschaft „TlsCertificateName“ ausführen:

Get-ReceiveConnector | ft server,name,tlscert* -AutoSize

Um den Parameter „TlsCertificateName“ anzupassen, orientiere ich mich hier.

Kurzversion…

1. 1. Thumbprint des neuen Zertifikats herausfinden und kopieren

      Get-ExchangeCertificate | ft Thumb*,Subject,Services,NOTAFTER

1. Zertifikat in eine Variable schreiben

   $cert = Get-ExchangeCertificate -Thumbprint 5CFA99C8709DAE9B447E166C53379F133FEED38C

2. Aussteller und Subject in eine weitere Variable schreiben

   $tlscertificatename = "$($cert.Issuer)$($cert.Subject)"

3. Jetzt setzen wir das Zertifikat und müssen keinen langen String schreiben

   Set-ReceiveConnector "MAILER\Client Frontend MAILER" -TlsCertificateName $tlscertificatename

4. Abschließend prüfen wir, ob der Parameter jetzt korrekt gesetzt ist

   Get-ReceiveConnector -Identity "MAILER\Client Frontend MAILER"  | ft server,name,tlscert* -AutoSize

   

Diesen Schritt für alle Konnektoren wiederholen, bei denen als Authentifizierungsvariante „ExchangeServer“ gesetzt ist.

Dienste an das Zertifikat binden

Jetzt müssen wir unser neues Zertifikat noch an die entsprechenden Dienste binden
Zwei einfache PowerShell Zeilen erledigt das…

1. Zuerst wieder den Thumbprint des Zertifikats holen…

   Get-ExchangeCertificate

2. Jetzt das neuen Zertifikat an die Dienste binden… (Unified Messaging lasse ich hier außen vor, da es nicht benötigt wird. Sollte das benötigt werden, muss vorab der UM Mode auf TLS gesetzt werden, da dieser standardmäßig im TCP Mode läuft.)

   Enable-ExchangeCertificate -Thumbprint 5CFA99C8709DAE9B447E166C53379F133FEED38C -Services IIS,SMTP,POP,IMAP

3. Die folgende Warnung bestätigen wir mit Ja und das wars…
4. Jetzt noch prüfen, ob die Dienste korrekt aktiviert sind…

   Get-ExchangeCertificate | ft friendly*,services

   

5. Abschließend noch via CMD ein

   iisreset

   um den IIS neu zu starten

6. Nach einigen Sekunden die Exchange Management GUI mit dem neuen Namen aufrufen, also https://mail.contoso.com/ecp und die Zertifikatsfehlermeldung, die bisher immer kam, sollte verschwunden sein…