PKI-Bereitstellungsoptionen für Exchange

Ab Exchange Server 2007 erstellt jeder Exchange-Server ein selbstsigniertes Standardzertifikat. Diese Out-of-the-Box …

Selbstsignierte Zertifikate ermöglichen es Exchange-Produktionsservern leider nicht, mit Clients oder Anwendungen von Drittanbietern zu kommunizieren. Folglich müssen Exchange-Administratoren zusätzliche Zertifikate von einer kommerziellen oder internen Zertifizierungsstelle bereitstellen. In diesem Tipp werden die Vor- und Nachteile der verfügbaren PKI-Bereitstellungsoptionen untersucht.
Es ist nicht ratsam, die Bedeutung digitaler Zertifikate in Exchange Server zu verwerfen. Sie sichern verschiedene Verbindungen und können auch Daten schützen. Nicht ordnungsgemäß bereitgestellte Zertifikate verursachen jedoch Probleme mit Exchange sowie mit Clients und integrierten Anwendungen wie Lync und SharePoint.
Über Exchange Server 2003 verfügten Administratoren nur über native Windows- und IIS-Zertifikatverwaltungstools. Exchange 2007 und neuere Versionen verwenden erweiterte Zertifikatfunktionen und bieten standardmäßig selbstsignierte Zertifikate und Verwaltungstools.
Da Exchange für alle Aspekte des Betriebs von fehlerfreien digitalen Zertifikaten abhängt, müssen Administratoren festlegen, um welche Art von Zertifikaten es sich handelt Public-Key-Infrastruktur (PKI) Bereitstellung, die sie verwenden werden: eine Werbung Zertifizierungsstelle (CA) oder eine interne CA-Bereitstellung.
Unabhängig davon, ob Sie eine kommerzielle oder interne Zertifizierungsstelle verwenden, müssen mehrere gängige PKI-Komponenten vorhanden sein, damit digitale Zertifikate ordnungsgemäß funktionieren:

  • Ein Stammzertifizierungsstellen-Server. Kommerzielle Stammzertifizierungsstellen stellen Exchange Server-Zertifikate nicht direkt aus. Sie sollten nicht verwendet werden, um dies in einem zu tun interne PKI Einsatz.
  • Ein selbstsigniertes Zertifikat der Stammzertifizierungsstelle. Alle Geräte, die Exchange mit einem Zertifikat dieser Zertifizierungsstelle veröffentlichen oder darauf zugreifen, benötigen das Zertifikat im entsprechenden Repository.
  • Ein oder mehrere zwischengeschaltete Zertifizierungsstellenserver. Zwischenserver-Server sind in einer internen CA-Bereitstellung zwar nicht erforderlich, bieten Ihnen jedoch eine bessere Flexibilität und Ausfallsicherheit im Betrieb.
  • Die Zertifikatsperrliste (Certificate Revocation List, CRL) der Zertifizierungsstelle. Diese Liste wird zum Veröffentlichen der IDs von widerrufenen Zertifikaten verwendet und sollte für alle Clientgeräte über HTTP zugänglich sein.
  • Ein Zwischenzertifizierungsstellenzertifikat für jede Zwischenzertifizierungsstelle in der Zertifikatkette, die von der Stammzertifizierungsstelle signiert ist. Exchange-Server und Veröffentlichungsgeräte wie Reverse-Proxys und Load Balancer benötigen diese Zertifikate. Clients können fehlende Zertifikate vom Server abrufen, solange die Stammzertifizierungsstelle vertrauenswürdig ist.
  • Das Exchange-Serverzertifikat. Dieses Zertifikat kann pro Server, pro Standort oder sogar pro Organisation ausgestellt werden. Es muss sich wahrscheinlich um ein SAN-Zertifikat handeln, dem ein privater Schlüssel zugeordnet ist.

Kommerzielle Zertifizierungsstellen

Öffentliche Zertifizierungsstellen sind bei kleineren Organisationen beliebt, da die Verwaltung von Client- und Gerätezertifikaten vereinfacht wird. Diese Zertifizierungsstellen haben bereits die entsprechenden Stamm- und Zwischenzertifizierungsstellenzertifikate an moderne Betriebssystem- und Mobilgerätehersteller verteilt. Daher sind sie standardmäßig auf neuen Computern und Geräten enthalten. Exchange-Administratoren müssen diese Zertifikate nicht manuell für neue mobile Geräte, Laptops und Desktops bereitstellen.
Öffentliche Zertifizierungsstellen bieten außerdem eine Kombination aus Kosten, Support und Reputation. Darüber hinaus bieten bestimmte öffentliche Zertifizierungsstellen Zertifikate an, die sichtbare Vertrauensbenachrichtigungen in Webbrowsern bereitstellen. Das heißt, sie sind für Exchange Server im Allgemeinen übertrieben – es sei denn, OWA ist für Ihr Unternehmen äußerst wichtig.
Bei einer großen Anzahl von zu verwaltenden Servern und Zertifikaten können die Kosten pro Zertifikat und die Verwaltungskomplexität unerschwinglich werden, insbesondere für E-Mail-Sicherheitsfunktionen wie z S / MIME. Außerdem sichern viele Exchange-Organisationen ihre Zertifikate nicht angemessen und planen keine Verzögerungen, die eine öffentliche Zertifizierungsstelle verursachen kann.

Interne Zertifizierungsstellen

Eine interne CA-Bereitstellung scheint eine einfache Entscheidung zu sein, da die Windows Active Directory-Zertifikatdienste (AD-CS) eine Reihe komplexer Funktionen zum Erstellen und Verwalten von Zertifikaten bieten. Wenn Sie AD-CS nicht verwenden möchten, bieten eine Reihe von Drittanbietern ihre eigenen CA-Produkte an. Es kann sich jedoch als schwierig erweisen, sicherzustellen, dass Clientgeräte internen CA-Zertifikaten vertrauen.
Bei von Unternehmen bereitgestellten Assets kann dies Teil des Erstellungsprozesses sein. Bei Mobilgeräten und BYOD-Programmen können durch Bereitstellung und Support jedoch Kosteneinsparungen vermieden werden. Interne Zertifikate schränken die Möglichkeit ein, den Datenverkehr zu anderen Systemen im Internet zu sichern, die den internen CA-Stammzertifikaten nicht vertrauen.
Durch das Bereitstellen interner Zertifizierungsstellen kann auch eine erstellt werden der Punkt des Versagens wenn falsch gemacht. Die Verwendung einer Stammzertifizierungsstelle zum Generieren von Zertifikaten scheint einfacher zu sein als eine zweistufige PKI mit Zwischenzertifizierungsstellen. Bei einem Serverausfall oder der Außerbetriebnahme eines Servers müssen Sie jedoch möglicherweise eine große Anzahl von Zertifikaten erneut ausstellen. Wenn die CRL nicht im Internet veröffentlicht wird, treten bei externen Benutzern und Systemen Probleme auf.

Hybrid-PKI-Bereitstellungsansätze

Die richtige Antwort könnte tatsächlich darin bestehen, die oben beschriebenen Ansätze zu kombinieren. Es gibt zwei Möglichkeiten, dies zu tun:

  • Verwenden Sie ein handelsübliches CA-Zertifikat. Viele öffentliche Zertifizierungsstellen verkaufen Zertifizierungsstellenzertifikate, obwohl sie erheblich teurer sind als Serverzertifikate. Diese Zwischenzertifizierungsstellenzertifikate werden dann mit den internen Zertifizierungsstellen verwendet, anstatt Ihre eigenen Zertifizierungsstellenzertifikate zu generieren. Die Stammzertifizierungsstelle ist öffentlich verfügbar und wird von Clientgeräten als vertrauenswürdig eingestuft.
  • Eine Kombination aus öffentlichen und internen Zertifikaten

    Abbildung 1. Ein Blick auf die Kombination von öffentlichen und internen Zertifikaten.

  • Verwenden Sie öffentliche Zertifikate zum Veröffentlichen und interne Zertifikate für alles andere. Diese Option weist öffentliche Zertifikate für eine Handvoll öffentlich zugänglicher Namen und Rollen zu, z. B. Reverse-Proxys, Load Balancer und nach außen gerichtete Brückenköpfe (siehe Abbildung 1).

Alle anderen Serverzertifikate werden von der internen PKI erstellt. Dieser Ansatz ist effektiv, da die Stärken eines CA-Typs verwendet werden, um die Schwächen des anderen auszugleichen.
Stellen Sie unabhängig von der gewählten Option sicher, dass Ihre Planung die Sicherheit, Sicherung und Redundanz Ihrer Zertifikatdaten und -systeme berücksichtigt.
Über den Autor
Devin Ganger ist ein Messaging-Architekt und technischer Redakteur mit mehr als 15 Jahren Erfahrung in der Verwaltung von Messaging-Systemen, Windows-, Unix- und TCP / IP-Netzwerken. Heute arbeitet er hauptsächlich mit Exchange Server, Windows Active Directory und verwandten Technologien von Microsoft und Drittanbietern. Ganger wurde von 2007 bis 2011 als Microsoft MVP für Exchange Server anerkannt.

Similar Posts

Leave a Reply