Exchange 2010: Best Practice für Zertifikate

kviolka · 11. März 2014

Hallo Exchange-Experten

ich habe folgendes Szenario:

eine interne Windows-Domäne mit 3 2008R2-Servern: AD-Server, RDP-Server, Exchange-Server
viele externe Büros sind über geroutetes Site-to-site-VPN mit dem Netz verbunden, können also den Exchange direkt über die interne IP-Adresse, etwa 10.1.1.123 ansprechen.
der Exchange soll bewusst nicht direkt aus dem Internet über eine öffentliche IP erreichbar sein.
Als Gateway für den Mailempfang habe ich einen Linux-Server mit Postfix, der als MX aus dem Internet erreichbar ist, Spams ablehnt und die Mail an den internen Exchange weiterreicht.
Die User verwenden zum einen Outlook 2010 auf dem RDP-Server.
Zum anderen sollen User aus den externen netzen via VPN auf die Weboberfläche des internen Exchange zugreifen können

Nun hab ich zwei Anforderungen:

User, die mit dem Browser aus einem externen VPN-Netz zugreifen, sollen keine Warnmeldung erhalten. Dabei möchte ich auf den Clients keine besonderen Root-Zertifikate installieren. Die Clients sind auch keine Domänenmitglieder, da gibt es auch MacOS-Clients etc.

Ich schon Erfahrung mit SSL-Zertifikaten, und habe erstmal diese einfache Lösung umgesetzt:

für meinen externen MX-Namen mail.meinefirma.de habe ich ein simples SSL-Zertifikat gekauft, wirklich ein ganz einfaches Domänenzertifikat. Die Zertfikats-Anforderung habe ich mit Hilfe des Exchange-Assistenten erstellt, und dabei nur den externen Host-Namen eingetragen.
Dieses Zertifikat hab ich im Exchange-Server nur dem ISS zugewiesen, keinen anderen Diensten (IMAP, POP...).
Mein Zertifikat wird auch brav von der OWA-Oberfläche ausgeliefert.
In den Routern meiner Client-Netze habe ich eine feste DNS-Einstellung von mail.meinefirma.de auf 10.3.1.10 gesetzt. Wenn man dort in einem Browser nun https://mail.meinefirma.de eingibt, funktioniert es wie gewünscht.
Dasselbe billige Zertfikat hab ich im Postfix für TLS hinterlegt. Der Test bei https://www.checktls.com/TestReceiver zeigt, dass alles funktioniert

Eigentlich ist alles schön so. Aber gestern hab ich gemerkt, dass sich nun die Outlook-Clients auf dem RDP-Server über das Zertifikat beschweren. Diese verwenden per Autoconfig den internen Servernamen EXC.meinefirma.local und dieser passt nicht zum Zertifikat.

Ich frage mich zwei Dinge: Warum kontrolliert Outlook 2010 das Webserver-Zertifikat? Bei den Verbindungseinstellungen ist der Haken "HTTP verwenden" nicht aktiviert.

Was ist im meinem Szenario die günstigste Zertifikat-Variante? Ein Multidomein-Zertifikat kann ich meines Wissens nicht für interne Domains kaufen, die nicht aus dem Internet erreichbar sind.

Vielen Dank für das Lesen schonmal und ich freue mich auf Tipps.

Karsten

bearbeitet 11. März 2014 von kviolka

NeMiX · 11. März 2014

Das Zertifikat EXC.meinefirma.local ist das Default Zertifikat oder kommt das von einer internen CA?

Du kannst das Zertifikat auf dem RDS Server importieren (im Computercontext der mmc) und dann sollte die Warnung weg sein.

RobertWi · 11. März 2014

Moin,

es gibt keinen eindeutigen "Best-Practise" für Zertifikate. Wenn es einen gäbe, würdest Du ihm Internet finden.

Was umgesetzt wird, hängt vom Geld, Zeit, Geräten, DNS, Proxy und Wünschen ab.

Und leider gehört auch Wissen dazu. Zum Beispiel das Wissen, dass Outlook mehrere Verbindungen zum OAB und EWS über HTTPS herstellt - immer.

Exchange-Technisch ist es bei Dir wahrscheinlich das beste, wenn Du SpltDNS einsetzt und die URLs für intern und extern auf den gleichen Wert setzt. Dann funktioniert allerdings Autodiscover für mobile Geräte nicht fehlerfrei, hierfür bräuchtest Du ein SAN-Zertifikat, in dem auf die feste Autodiscover-URL enthalten ist.

Wenn Dir jetzt schon der Kopf bei den Begriffen raucht, wäre das Hinzuziehen eines externen Beraters eventuell die effektivste Lösung. Ansonsten wirst Du sehr viel Zeit zum Lesen und Durchdenken brauchen. Ein guter Anfang (aber längst nicht vollständig) ist hier:

http://www.msxfaq.de/howto/e2k7ssl.htm

http://www.msxfaq.de/signcrypt/sancert.htm

http://www.msxfaq.de/konzepte/namenswahl.htm