Bei einem Kunden wurde das auf einem Exchange 2010 installierte SSL-Zertifikat demnächst ungültig. Ich habe mich mit meinem bevorzugtem Zertifikat-Lieferanten Comodo in Verbindung gesetzt und dort gelernt, dass für einen Exchangeserver aus diversen Gründen ein „SSL UC Certificate“ das bevorzugte Produkt ist.
Der Hauptunterschied zu normalen SSL-Zertifikaten (günstiger) und Wildcard-Zertifikaten (teurer) ist neben dem Preis die Tatsache, dass mit einem UC-Zertifikat eine begrenzte Anzahl FQDNs (bei Comodo sind 3 enthalten; zusätzliche sind gegen Aufpreis möglich) aus völlig verschiedenen Domains mit einem einzigen Zertifikat geschützt werden können. Ich habe in diesem Fall kunde.de, owa.kunde.de und rdp.kunde.de gewählt.
Zuerst muß man entweder mit dem Assistenten in der Exchange Console oder wie in der Comodo Knowledgebase erklärt mit der Exchange Shell einen neuen Certificate Request (CSR) erzeugen und mit diesem auf der Comodo-Website ein Zertifikat bestellen. Dieses erhält man als ZIP-Datei, die das neue Zertifikat und zusätzlich auch noch das Root- und das Intermediate-Zertifikat von Comodo enthält, falls diese benötigt werden (dazu gibt es einen eigenen Knowledgebase-Artikel). Das neue Zertifikat installiert man dann – je nach dem wie man den CSR erzeugt hat – entweder wieder über die Exchange Console oder über die Exchange Shell. Damit ist dann der Zugriff auf Outlook Web App (OWA) über https://owa.kunde.de/owa wieder sauber verschlüsselt möglich.
Da das UC-Zertifikat aber noch den zusätzlichen FQDN rdp.kunde.de beinhaltet, wollte ich den Zugriff auf den Terminalserver per RDP damit absichern. Dazu habe ich das UC-Zertifikat zuerst mit dem Certificates SnapIn der MMC wieder exportiert (mit Private Key und allen Zertifikaten im Zertifikatspfad) und anschließend am Terminalserver auf die gleiche Art (also Certificates SnapIn der MMC) in das lokale Computerkonto unter „Personal“ importiert. Damit ist das UC-Zertifikat dem Terminalserver bekannt und kann wie hier beschrieben in der „Remote Desktop Session Host Configuration“ zugewiesen werden. Danach sind sauber verschlüsselte RDP-Verbindungen möglich, die am „Schloß-Symbol“ in der RDP-Verbindungsleiste erkennbar sind.
[Update] Leider hat sich am nächsten Tag noch ein „kleines“ Problem ergeben: Wie ich gelernt habe, werden Zertifikate die interne FQDNs enthalten nur noch bis zum 31.10.2015 ausgegeben. Da ich das oben beschriebene UC-Zertifikat aber gleich für 3 Jahre gekauft habe, konnte ich es deshalb nur ohne den internen FQDN des Exchangeservers exchange.kunde.local kaufen. Nach dem Start von Outlook an den Arbeitsplätzen im Büro wurde deshalb folgerichtig eine Warnung angezeigt, dass das Zertifikat nicht den aktuellen Servernamen exchange.kunde.local enthält.
Die Lösung für das Problem ist die Verwendung des externen FQDN (owa.kunde.de) des Exchangeservers auch im internen Netz, denn dann stimmt das Zertifikat natürlich wieder. Dazu muß erstens dafür gesorgt werden dass im internen Netz der externe FQDN des Exchangeservers mit der internen IP aufgelöst wird und zweitens im Exchange die Einträge für die „internal URL“ geändert werden.
- Die Lösung des DNS-Problems heißt „Split-DNS„. Eine Beschreibung der hier erforderlichen einfachsten Form (nur ein einziger interner Server muß behandelt werden) habe ich in einem Blog gefunden. Letztlich legt man im internen DNS eine neue Zone owa.kunde.de an und erzeugt darin nur einen A-Record, beim man die interne IP-Adresse des Exchangeservers einträgt und den Namen leer läßt. Damit wird owa.kunde.de intern mit der korrekten internen IP-Adresse aufgelöst und extern natürlich völlig unverändert mit der externen IP-Adresse.
- Die Änderung der Einträge für die „internal URL“ im Exchange wird in der MS Knowledgebase (KB 940726) reichlich theoretisch und unverständlich erklärt. In einem Blog habe ich eine deutlich verständlichere „Übersetzung“ gefunden. Einfach wie beschrieben mit der Exchange Shell zuerst die 3 alten Werte auslesen und dokumentieren und dann die neuen Werte eintragen. Nach einem Server-Neustart funktioniert alles wie gewünscht: Outlook im Büro startet wieder ohne Zertifikats-Warnung und OWA von extern läuft nach wie vor sauber.