Grundlegendes zu digitalen Zertifikaten und SSL

Gilt für: Exchange Server 2010

Letztes Änderungsdatum des Themas: 2009-12-01

SSL (Secure Sockets Layer) ist ein Verfahren zum Schutz der Kommunikation zwischen einem Client und einem Server. Für einen Microsoft Exchange Server 2010-Clientzugriffsserver wird SSL zur Absicherung der Kommunikation zwischen Server und Clients verwendet. Clients sind z. B. mobile Geräte, Computer im Netzwerk einer Organisation sowie Computer außerhalb des Netzwerks einer Organisation. Dazu zählen Clients mit und ohne VPN-Verbindungen (Virtual Private Network).

Bei der Installation von Exchange 2010 wird die Clientkommunikation standardmäßig unter Verwendung von SSL verschlüsselt, wenn Sie Microsoft Office Outlook-Webanwendung, Exchange ActiveSync und Outlook Anywhere verwenden. Standardmäßig ist für POP3 (Post Office Protocol, Version 3) und IMAP4 (Internet Message Access Protocol, Version 4, Rev1) keine Kommunikation über SSL konfiguriert.

SSL setzt voraus, dass Sie digitale Zertifikate verwenden. In diesem Thema erhalten Sie einen Überblick über die verschiedenen Arten von digitalen Zertifikaten und Informationen dazu, wie Sie den Clientzugriffsserver zur Verwendung dieser digitalen Zertifikate konfigurieren.

Inhalt

Übersicht über digitale Zertifikate

Digitale Zertifikate und Proxyfunktion

Bewährte Methoden für digitale Zertifikate

Clienteinschränkungen

Übersicht über digitale Zertifikate

Digitale Zertifikate sind elektronische Dateien, die wie Onlinekennwörter funktionieren, um die Identität eines Benutzers oder eines Computers zu überprüfen. Sie werden verwendet, um den SSL-verschlüsselten Kanal zu erstellen, der für die Clientkommunikation verwendet wird. Ein Zertifikat ist eine digitale Bescheinigung von einer Zertifizierungsstelle (Certification Authority, CA), die die Identität des Zertifikatinhabers bestätigt und den Parteien eine sichere Kommunikation durch die Verschlüsselung von Daten ermöglicht.

Digitale Zertifikate bewirken Folgendes:

• Sie bestätigen, dass ihre Inhaber – Personen, Websites und sogar Netzwerkressourcen wie z. B. Router – wirklich das sind, was sie vorgeben zu sein.
• Sie schützen online ausgetauschte Daten vor Diebstahl und Manipulation.

Digitale Zertifikate können von einer vertrauenswürdigen Zertifizierungsstelle eines Drittanbieters oder einer Microsoft Windows-PKI (Public Key-Infrastruktur) unter Verwendung von Zertifikatdiensten ausgestellt werden oder selbstsigniert sein. Jeder Zertifikattyp hat Vor- und Nachteile. Alle Arten von digitalen Zertifikaten sind manipulationssicher und können nicht gefälscht werden.

Zertifikate können für verschiedene Zwecke ausgestellt werden, beispielsweise zur Webbenutzerauthentifizierung, zur Webserverauthentifizierung, für S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol Security), TLS (Transport Layer Security) und zur Codesignierung.

Ein Zertifikat enthält einen öffentlichen Schlüssel und bindet diesen an die Identität einer Person, eines Computers oder eines Diensts mit dem entsprechenden privaten Schlüssel. Öffentliche und private Schlüssel werden vom Client und vom Server zum Verschlüsseln von Daten vor deren Übertragung verwendet. Für Windows-basierte Benutzer, Computer und Dienste wird eine Vertrauensstellung mit einer Zertifizierungsstelle eingerichtet, wenn sich eine Kopie des Stammzertifikats im Informationsspeicher für vertrauenswürdige Stammzertifikate befindet und das Zertifikat einen gültigen Zertifizierungspfad enthält. Damit das Zertifikat gültig ist, darf es nicht gesperrt worden sein, und der Gültigkeitszeitraum darf nicht abgelaufen sein.

Zertifikattypen

Es gibt drei wichtige Arten von digitalen Zertifikaten: selbstsignierte Zertifikate, Windows PKI-generierte Zertifikate und Zertifikate von Drittanbietern.

Selbstsignierte Zertifikate

Bei der Installation von Exchange 2010 wird automatisch ein selbstsigniertes Zertifikat konfiguriert. Ein selbstsigniertes Zertifikat wird von der Anwendung signiert, die es erstellt hat. Antragsteller und Name des Zertifikats stimmen überein. Der Aussteller und der Antragsteller sind im Zertifikat definiert. Ein selbstsigniertes Zertifikat erlaubt einigen Clientprotokollen die Verwendung von SSL für die Kommunikation. Exchange ActiveSync und Outlook-Webanwendung können eine SSL-Verbindung unter Verwendung eines selbstsignierten Zertifikats herstellen. Outlook Anywhere unterstützt keine selbstsignierten Zertifikate. Selbstsignierte Zertifikate müssen manuell in den Informationsspeicher für vertrauenswürdige Stammzertifikate auf dem Clientcomputer oder auf dem mobilen Gerät kopiert werden. Wenn ein Client über SSL eine Verbindung zum Server herstellt und der Server ein selbstsigniertes Zertifikat anbietet, wird der Client aufgefordert zu überprüfen, ob das Zertifikat von einer vertrauenswürdigen Stelle ausgestellt wurde. Zwischen dem Client und dem Aussteller des Zertifikats muss eine ausdrückliche Vertrauensstellung bestehen. Bestätigt der Client die Vertrauensstellung, kann die SSL-Kommunikation fortgesetzt werden.

Kleine Organisationen entscheiden sich häufig gegen die Verwendung eines Drittanbieterzertifikats oder die Installation einer eigenen PKI zur Ausstellung eigener Zertifikate, da sie die Kosten scheuen und/oder ihre Administratoren nicht über entsprechende Erfahrungen und Kenntnisse bei der Erstellung einer eigenen Zertifikathierarchie verfügen. Bei der Verwendung von selbstsignierten Zertifikaten sind die Kosten minimal, und die Einrichtung ist einfach. Das Erstellen einer Infrastruktur zur Lebenszyklusverwaltung, Erneuerung, Vertrauensverwaltung und Sperrung von Zertifikaten ist bei selbstsignierten Zertifikaten jedoch wesentlich schwieriger.

Windows PKI-Zertifikate

Der zweite Zertifikattyp ist das Windows PKI-generierte Zertifikat. Bei einer PKI (Public Key-Infrastruktur) handelt es sich um ein System von digitalen Zertifikaten, Zertifizierungsstellen (Certification Authorities, CAs) und Registrierungsstellen (Registration Authorities, RAs), das zum Prüfen und Authentifizieren der Gültigkeit der an der elektronischen Transaktion beteiligten Parteien die Kryptografie mit öffentlichen Schlüsseln verwendet. Wenn Sie eine Public Key-Infrastruktur in einer Organisation implementieren, in der Active Directory verwendet wird, stellen Sie eine Infrastruktur für Lebenszyklusverwaltung, Erneuerung, Vertrauensverwaltung und Sperrung von Zertifikaten zur Verfügung. Bei der Bereitstellung von Servern und der Infrastruktur zum Erstellen und Verwalten von Windows PKI-generierten Zertifikaten entstehen jedoch zusätzliche Kosten.

Zur Bereitstellung einer Windows PKI sind die Zertifikatdienste erforderlich, die über die Option Software in der Systemsteuerung installiert werden können. Sie können die Zertifikatdienste auf jedem Server in der Domäne installieren.

Wenn Sie Zertifikate von einer mit der Domäne verbundenen Windows-Zertifizierungsstelle anfordern, können Sie über die Zertifizierungsstelle Zertifikate für Ihre eigenen Server oder Computer im Netzwerk anfordern oder signieren. Auf diese Weise können Sie eine PKI verwenden, die einem Zertifikatdrittanbieter ähnelt, jedoch weniger kostspielig ist. Wenngleich diese PKI-Zertifikate nicht wie andere Zertifikattypen öffentlich bereitgestellt werden können, wird der Requestor überprüft, wenn eine PKI-Zertifizierungsstelle das Zertifikat des Requestors mithilfe des privaten Schlüssels signiert. Der öffentliche Schlüssel dieser Zertifizierungsstelle ist Bestandteil des Zertifikats. Ein Server, in dessen Informationsspeicher für vertrauenswürdige Stammzertifikate sich dieses Zertifikat befindet, kann den öffentlichen Schlüssel zum Entschlüsseln des Requestorzertifikats verwenden und den Requestor authentifizieren.

Die Schritte zum Bereitstellen eines PKI-generierten Zertifikats gleichen denen zur Bereitstellung eines selbstsignierten Zertifikats. Sie müssen ebenfalls eine Kopie des vertrauenswürdigen Stammzertifikats aus der Public Key-Infrastruktur in den Informationsspeicher für vertrauenswürdige Stammzertifikate auf den Computern oder mobilen Geräten installieren, deren Verbindung mit Microsoft Exchange über SSL hergestellt werden soll.

Eine Windows PKI ermöglicht Organisationen, eigene Zertifikate zu veröffentlichen. Clients können Zertifikate von einer Windows PKI im internen Netzwerk anfordern und erhalten. Die Windows PKI kann Zertifikate erneuern oder sperren.

Vertrauenswürdige Zertifikate von Drittanbietern

Bei Drittanbieter- oder kommerziellen Zertifikaten handelt es sich um Zertifikate, die von einer Drittanbieter- oder kommerziellen Zertifizierungsstelle erzeugt werden und die Sie anschließend zur Verwendung auf Ihren Netzwerkservern erwerben können. Bei selbstsignierten und PKI-basierten Zertifikaten besteht das Problem, dass das Zertifikat vom Clientcomputer oder mobilen Gerät nicht automatisch als vertrauenswürdig eingestuft wird. Sie müssen sicherstellen, dass das Zertifikat in den Informationsspeicher für vertrauenswürdige Stammzertifikate auf Clientcomputern und anderen Geräten importiert wird. Bei kommerziellen Zertifikaten oder Zertifikaten von Drittanbietern tritt dieses Problem nicht auf. Die meisten kommerziellen CA-Zertifikate werden bereits als vertrauenswürdig eingestuft, da sich das Zertifikat bereits im Informationsspeicher für vertrauenswürdige Stammzertifikate befindet. Da der Aussteller als vertrauenswürdig eingestuft wird, gilt dies auch für das Zertifikat. Die Verwendung von Drittanbieterzertifikaten vereinfacht die Bereitstellung erheblich.

Größere Organisationen oder Organisationen, die Zertifikate öffentlich bereitstellen müssen, sollten Drittanbieter- oder kommerzielle Zertifikate verwenden, auch wenn dies mit Kosten verbunden ist. Für kleine und mittelständische Organisationen stellen kommerzielle Zertifikate unter Umständen nicht die beste Lösung dar, und es sollten andere Zertifikatoptionen in Betracht gezogen werden.

Auswählen eines Zertifikattyps

Bei der Auswahl des zu installierenden Zertifikattyps sind verschiedene Faktoren zu berücksichtigen. Ein Zertifikat ist nur gültig, wenn es signiert ist. Es kann selbstsigniert oder von einer Zertifizierungsstelle signiert sein. Für ein selbstsigniertes Zertifikat gelten bestimmte Einschränkungen. Beispielweise ist es nicht auf allen mobilen Geräte möglich, ein digitales Zertifikat im Informationsspeicher für vertrauenswürdige Stammzertifikate zu installieren. Ob Sie Zertifikate auf einem mobilen Gerät installieren können, hängt vom Hersteller des mobilen Geräts und vom Mobilfunkanbieter ab. Einige Hersteller und Mobilfunkanbieter deaktivieren den Zugriff auf den Informationsspeicher für vertrauenswürdige Stammzertifikate. In diesem Fall können Sie weder ein selbstsigniertes Zertifikat noch ein Zertifikat einer Windows PKI-Zertifizierungsstelle auf dem mobilen Gerät installieren.

Auf den meisten mobilen Geräten sind verschiedene vertrauenswürdige kommerzielle Zertifikate von Drittanbietern vorinstalliert. Implementieren Sie für ein optimales Benutzererlebnis die zertifikatbasierte Authentifizierung für Exchange ActiveSync, indem Sie Geräte mit Windows Mobile 6.0 oder einer höheren Version und einem digitalen Zertifikat von einer vertrauenswürdigen Drittanbieter-Zertifizierungsstelle verwenden.

Standardmäßige Exchange-Zertifikate

Exchange installiert standardmäßig ein selbstsigniertes Zertifikat, sodass die gesamte Netzwerkkommunikation verschlüsselt wird. Zum Verschlüsseln der gesamten Netzwerkkommunikation ist es erforderlich, dass alle Exchange-Server über ein X.509-Zertifikat verfügen. Sie sollten dieses selbstsignierte Zertifikat durch ein Zertifikat ersetzen, dem Ihre Clients automatisch vertrauen.

"Selbstsigniert" bedeutet, dass ein Zertifikat durch den Exchange-Server erstellt und signiert wurde. Da das Zertifikat nicht durch eine vertrauenswürdige Zertifizierungsstelle erstellt und signiert wurde, wird das selbstsignierte Zertifikat nur von anderen Exchange-Servern, nicht jedoch von anderen Softwarekomponenten als vertrauenswürdig eingestuft. Das Standardzertifikat ist für alle Exchange-Dienste aktiviert. Der Name des alternativen Antragstellers im Zertifikat entspricht dem Namen des Exchange-Servers, auf dem das Zertifikat installiert ist. Darüber hinaus enthält das Zertifikat eine Liste von SANs, die sowohl den Servernamen als auch den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servers umfasst.

Wenngleich andere Exchange-Server in Ihrer Exchange-Organisation diesem Zertifikat automatisch vertrauen, stufen Clients wie z. B. Webbrowser, Outlook-Clients, Mobiltelefone und andere E-Mail-Clients sowie externe E-Mail-Server das Zertifikat nicht automatisch als vertrauenswürdig ein. Daher sollten Sie erwägen, das Zertifikat auf den Exchange-Servern mit installierter Clientzugriffs-Serverrolle sowie auf allen nach außen sichtbaren Hub-Transport-Servern durch ein vertrauenswürdiges Drittanbieterzertifikat zu ersetzen. Wenn Sie über eine eigene Public Key-Infrastruktur verfügen und alle Ihre Clients dieser Entität vertrauen, können Sie auch Zertifikate verwenden, die Sie selbst ausgestellt haben.

Zertifikatanforderungen nach Dienst

Zertifikate werden in Exchange für verschiedene Zwecke eingesetzt. Die meisten Kunden verwenden Zertifikate außerdem auf mehreren Exchange-Servern. Im Allgemeinen gilt die Regel, dass weniger Zertifikate einfacher zu verwalten sind.

IIS

Die folgenden Exchange-Dienste verwenden auf einem Exchange-Server dasselbe Zertifikat: 

• Outlook-Webanwendung
• Exchange-Systemsteuerung
• Exchange-Webdienste
• Exchange ActiveSync
• Outlook Anywhere
• AutoErmittlung
• Outlook-Adressbuchverteilung

Da einer Website nur ein einziges Zertifikat zugeordnet werden kann, und da alle genannten Dienste standardmäßig über eine einzelne Website bereitgestellt werden, müssen alle Namen im Zertifikat aufgeführt werden (oder unter einen Platzhalternamen im Zertifikat fallen), die Clients für diese Dienste verwenden.

POP/IMAP

Für POP oder IMAP verwendete Zertifikate können separat von dem Zertifikat angegeben werden, das für IIS verwendet wird. Um jedoch die Verwaltung zu vereinfachen, wird empfohlen, die POP- oder IMAP-Dienstnamen in Ihr IIS-Zertifikat aufzunehmen und ein einziges Zertifikat für sämtliche dieser Dienste zu verwenden.

SMTP

Für jeden Empfangsconnector, den Sie auf Ihren Hub-Transport- oder Edge-Transport-Servern verwenden, kann ein separates Zertifikat verwendet werden. Das Zertifikat muss den Namen des SMTP-Clients (oder anderer SMTP-Server) enthalten, der bzw. die zum Kontaktieren des Connectors verwendet werden. Zur einfacheren Zertifikatverwaltung können Sie alle Namen, für die TLS-Datenverkehr unterstützt werden muss, in einem einzelnen Zertifikat zusammenfassen.

Live-Verbund

Das Zertifikat für einen Verbund mit Windows Live für Exchange kann einen beliebigen Namen enthalten. Bei der Verbunderstellung geben Sie das Zertifikat an, das der Exchange-Server verwenden soll. Bei diesem Zertifikat muss es sich um ein Zertifikat einer Drittanbieter-Zertifizierungsstelle handeln, die von Windows Live als vertrauenswürdig eingestuft wird. Wenn Sie Ihr Exchange-Zertifikat für andere Dienste von einer Drittanbieter-Zertifizierungsstelle erwerben, die von Windows Live als vertrauenswürdig eingestuft wird, können Sie ein einziges Zertifikat für diese Dienste und auch für den Verbund mit Windows Live verwenden.

Unified Messaging

Wenn Exchange Unified Messaging-Server eine Verbindung mit Microsoft Office Communications Server 2007-Servern oder Drittanbieter-SIP-Gateways oder PBX-Telefonsystemen (Private Branch eXchange) herstellen, müssen Sie ein Zertifikat mit dem FQDN der Unified Messaging-Server verwenden. Sie erreichen dies durch ein Platzhalterzertifikat für alle Unified Messaging-Server verwenden. Hierzu nehmen Sie die FQDNs Ihrer Unified Messaging-Server in die SAN-Liste des Zertifikats auf oder stellen ein separates Zertifikat für jeden Unified Messaging-Server bereit, das den FQDN im Zertifikat-SAN enthält. Es wird empfohlen, die FQDNs der Unified Messaging-Server in die SAN-Liste des Zertifikats aufzunehmen.

Instant Messaging in Outlook Web App mit Office Communications Server 2007 R2

Outlook-Webanwendung in Exchange 2010 umfasst eine Programmierschnittstelle, die Instant Messaging-Anbietern das Schreiben von Add-Ins zur Steuerung von Präsenz- und IM-Funktionalität (Instant Messaging) ermöglicht. Für Communications Server 2007 R2 ist ein Add-In vorhanden. Wenn Sie dieses Add-In verwenden, müssen Sie ein Zertifikat zum Absichern der Verbindung zwischen dem Communications Server 2007 R2-Server und dem Exchange 2010-Clientzugriffsserver verwenden. Das Zertifikat muss auf den Exchange-Clientzugriffsservern installiert werden.

Legacy-Exchange-Server

Wenn Sie den bewährten Methoden für den Wechsel von Microsoft Exchange Server 2003 oder Exchange Server 2007 auf Exchange 2010 folgen, führen Sie einen neuen Hostnamen – legacy.contoso.com – ein, der während der Koexistenz beider Versionen verwendet wird, wenn Sie Postfächer sowohl auf Legacyversionen von Exchange als auch auf Exchange 2010 ausführen. Dieser Legacyhostname sollte auch in das verwendete Zertifikat aufgenommen werden. Weitere Informationen zum Upgrade von Exchange Server 2003 und Exchange 2007 auf Exchange 2010 finden Sie unter Upgrade von Exchange 2003 für den Clientzugriff und Upgrade von Exchange 2007 für den Clientzugriff.

Digitale Zertifikate und Proxyfunktion

Als Proxyfunktion wird die Methode bezeichnet, mit der ein Clientzugriffsserver Clientverbindungen an einen anderen Clientzugriffsserver sendet. Es gibt zwei Szenarien, in denen ein Clientzugriffsserver über einen Proxy Datenverkehr an einen anderen Clientzugriffsserver weiterleitet.

1. Clientzugriffsserver an einem mit dem Internet verbundenen Active Directory-Standort leiten Datenverkehr über einen Proxy an Clientzugriffsserver weiter, die sich an einem nicht mit dem Internet verbundenen Standort befinden. Auf diese Weise wird sichergestellt, dass die gesamte Verarbeitung von Clientanforderungen in möglichst geringer Entfernung zum Clientpostfachserver durchgeführt wird.
2. Clientzugriffsserver für Exchange 2010 leiten Verbindungen von Clients über einen Proxy weiter, die über Postfächer auf Exchange 2003 oder Exchange 2007 verfügen. Diese Clientverbindungen werden über einen Proxy an Exchange 2007-Clientzugriffsserver weitergeleitet. Dies geschieht, da der Clientzugriffsserver für viele Exchange-Dienste keine Anforderungen für Postfachserver verarbeiten kann, die eine ältere Version von Exchange ausführen.

Wenn Clientzugriffsserver Anforderungen über einen Proxy weiterleiten, wird SSL für die Verschlüsselung, nicht jedoch für die Authentifizierung verwendet. In den meisten Fällen kann ein selbstsigniertes Zertifikat für die Proxyfunktion des Clientzugriffsservers verwendet werden. Wenn für Ihre Organisation besonders strenge Sicherheitsrichtlinien gelten, können Sie über einen Konfigurationsschlüssel die Verwendung von vertrauenswürdigen Zertifikaten für die Proxyfunktion des Clientzugriffsservers erzwingen. Sie können in diesem Szenario den folgenden Schlüssel auf FALSE setzen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts

Eine fehlerhafte Bearbeitung der Registrierung kann zu schwerwiegenden Problemen führen, die eine Neuinstallation des Betriebssystems erforderlich machen kann. Durch fehlerhafte Bearbeitung der Registrierung verursachte Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie alle wichtigen Daten, bevor Sie die Registrierung bearbeiten.

Weitere Informationen zur Proxyfunktion finden Sie unter Understanding Proxying and Redirection.

Reverseproxys und Zertifikate

Die meisten Exchange-Bereitstellungen verwenden Reverseproxys zum Veröffentlichen von Exchange-Dienste im Internet. Beispiele für populäre Reverseproxyprodukte sind Microsoft Internet Security and Acceleration (ISA) Server und Checkpoint. Diese Reverseproxys können so konfiguriert werden, dass sie die SSL-Verschlüsselung beenden, den Datenverkehr als Klartext auf dem Server untersuchen und dann einen neuen SSL-Verschlüsselungskanal vom Reverseproxyserver zu den Exchange-Servern öffnen, die sich hinter dem Reverseproxy befinden. Dieser Vorgang wird als SSL-Bridging bezeichnet. Eine weitere Methode zum Konfigurieren der Reverseproxyserver besteht darin, die SSL-Verbindungen direkt an die Exchange-Server hinter den Reverseproxyservern weiterzuleiten. In beiden Bereitstellungsmodellen stellen die Clients im Internet über einen Hostnamen für den Exchange-Zugriff, z. B. mail.contoso.com, eine Verbindung zum Reverseproxyserver her. Dann verbindet sich der Reverseproxy über einen anderen Hostnamen, z. B. dem Computernamen des Exchange-Clientzugriffsservers, mit Exchange. Sie müssen den Computernamen nicht in das Zertifikat auf dem Exchange-Clientzugriffsserver aufnehmen, da die gängigen Reverseproxyserver in der Lage sind, den ursprünglichen Hostnamen, den der Client verwendet, dem internen Hostnamen des Exchange-Clientzugriffsservers zuzuordnen.

Lastenausgleich und Zertifikate

Wenn Sie über mehr als einen Clientzugriffsserver verfügen, sollten Sie die Konfiguration eines Clientzugriffsserver-Arrays erwägen. Durch dieses Array können alle Clients über einen einzigen Hostnamen eine Verbindung zu Ihren Exchange-Clientzugriffsservern herstellen. Sie können einem Clientzugriffsserver-Array beliebig viele Clientzugriffsserver hinzufügen – vorausgesetzt, alle Clientzugriffsserver befinden sich am selben Active Directory-Standort. Weitere Informationen zu Lastenausgleich und Clientzugriffsserver-Arrays finden Sie unter Understanding Proxying and Redirection und Verwalten von Clientzugriffsservern.

SSL und Split-DNS

Split-DNS ist eine Technologie, die Ihnen das Konfigurieren unterschiedlicher IP-Adressen für denselben Hostnamen ermöglicht – abhängig davon, woher die ursprüngliche DNS-Anforderung stammt. Diese Technologie wird auch als Split-Horizon-DNS, Split-View-DNS oder Split-Brain-DNS bezeichnet. Mit Split-DNS können Sie die Anzahl von Hostnamen verringern, die für Exchange verwaltet werden. Dies wird erreicht, indem Sie Ihren Clients – unabhängig davon, ob sie sich über das Internet oder aus dem Intranet verbinden – ermöglichen, über denselben Hostnamen eine Verbindung mit Exchange herzustellen. Split-DNS macht es möglich, dass aus dem Intranet stammende Anforderungen eine andere IP-Adresse erhalten als Anforderungen, die aus dem Internet empfangen werden.

Split-DNS ist in einer kleinen Exchange-Bereitstellung üblicherweise nicht erforderlich, da Benutzer unabhängig davon, ob die Anforderung aus dem Intranet oder dem Internet stammt, auf denselben DNS-Endpunkt zugreifen. In größeren Bereitstellung jedoch führt diese Konfiguration zu einer Überlastung Ihrer ausgehenden Internetproxyserver und Ihrer Reverseproxyserver. In größeren Bereitstellungen sollte daher Split-DNS konfiguriert werden, damit externe Benutzer auf "mail.contoso.com" und interne Benutzer auf "internal.contoso.com" zugreifen. Die Verwendung von Split-DNS für diese Konfiguration stellt sicher, dass sich Ihre Benutzer keine unterschiedlichen Hostnamen für ihren jeweiligen Standort merken müssen.

Remote-PowerShell

Kerberos-Authentifizierung und Kerberos-Verschlüsselung werden für den Zugriff auf Remote-PowerShell verwendet, sowohl von der Exchange-Verwaltungskonsole als auch von der Exchange-Verwaltungsshell. Daher müssen Sie Ihre SSL-Zertifikate nicht zur Verwendung mit Remote-PowerShell konfigurieren.

Bewährte Methoden für digitale Zertifikate

Wenngleich die Konfiguration der digitalen Zertifikate Ihrer Organisation basierend auf Ihren spezifischen Anforderungen variiert, sollen die nachfolgend aufgeführten bewährten Methoden Sie bei der Auswahl der richtigen Konfiguration für Ihre digitalen Zertifikate unterstützen.

Bewährte Methode: Verwenden eines vertrauenswürdigen Drittanbieterzertifikats

Um zu verhindern, dass Clients Fehler zu nicht vertrauenswürdigen Zertifikaten erhalten, muss das von Ihrem Exchange-Server verwendete Zertifikat durch eine Stelle ausgegeben worden sein, die der Client als vertrauenswürdig einstuft. Wenngleich die meisten Clients so konfiguriert werden können, dass sie einem beliebigen Zertifikat oder Zertifikataussteller vertrauen, ist es einfacher, auf Ihrem Exchange-Server ein vertrauenswürdiges Drittanbieterzertifikat zu verwenden. Dies liegt daran, dass die meisten Clients bereits ihren Stammzertifikaten vertrauen. Es gibt verschiedene Drittanbieter-Zertifizierungsstellen, die speziell für Exchange konfigurierte Zertifikate anbieten. Sie können die Exchange-Verwaltungskonsole zum Generieren von Zertifikatanforderungen verwenden, die für die meisten Zertifikataussteller genutzt werden können.

Auswählen einer Zertifizierungsstelle

Eine Zertifizierungsstelle ist ein Unternehmen, das Zertifikate ausstellt und deren Gültigkeit sicherstellt. Clientsoftware (beispielsweise Browser wie Microsoft Internet Explorer oder Betriebssysteme wie Windows oder Mac OS) verfügen über eine integrierte Liste vertrauenswürdiger Zertifizierungsstellen. Es ist im Allgemeinen möglich, dieser Liste Zertifizierungsstellen hinzuzufügen bzw. Zertifizierungsstellen aus der Liste zu entfernen, aber die Konfiguration ist häufig langwierig. Berücksichtigen Sie bei der Auswahl einer Zertifizierungsstelle für den Erwerb von Zertifikaten die folgenden Aspekte:

• Stellen Sie sicher, dass die Clientsoftware (Betriebssysteme, Browser und Mobiltelefone), die eine Verbindung mit Ihren Exchange-Servern herstellen, die Zertifizierungsstelle als vertrauenswürdig einstufen.
• Wählen Sie eine Zertifizierungsstelle, die "Unified Communications-Zertifikate" zur Verwendung mit dem Exchange-Server unterstützt.
• Stellen Sie sicher, dass die Zertifizierungsstelle die Arten von Zertifikaten unterstützt, die Sie verwenden möchten. Ziehen Sie die Verwendung von SAN-Zertifikaten (Subject Alternative Name) in Betracht. Nicht alle Zertifizierungsstellen unterstützen SAN-Zertifikate, und einige Zertifizierungsstellen unterstützen möglicherweise nicht die benötigte Anzahl von Hostnamen.
• Stellen Sie sicher, dass die für die Zertifikate erworbene Lizenz es Ihnen ermöglicht, das Zertifikat für die Anzahl von Servern zu verwenden, die Sie einsetzen möchten. Bei einigen Zertifizierungsstellen darf ein Zertifikat nur auf einem Server verwendet werden.
• Vergleichen Sie die Zertifikatpreise verschiedener Zertifizierungsstellen.

Bewährte Methode: Verwenden von SAN-Zertifikaten

Abhängig davon, wie Sie die Dienstnamen in Ihrer Exchange-Bereitstellung konfigurieren, erfordert Ihr Exchange-Server möglicherweise ein Zertifikat, dass mehrere Domänennamen repräsentieren kann. Wenngleich ein Platzhalterzertifikat, z. B. für *.contoso.com, dieses Problem lösen kann, haben viele Kunden Bedenken in Bezug auf die Sicherheitsrisiken eines solchen Zertifikats, das für eine beliebige Unterdomäne verwendet werden kann. Sicherer ist es, die erforderlichen Domänen als alternative Antragstellernamen (Subject Alternative Names, SANs) im Zertifikat aufzuführen. Beim Generieren von Zertifikatanforderungen in Exchange wird standardmäßig diese Methode gewählt.

Bewährte Methode: Verwenden des Assistenten für Exchange-Zertifikate zum Anfordern von Zertifikaten

Es gibt zahlreiche Dienste in Exchange, die Zertifikate verwenden. Ein häufiger Fehler beim Anfordern von Zertifikaten besteht darin, bei der Anforderung nicht die richtigen Dienstnamen einzuschließen. Der Assistent zum Anfordern von Zertifikaten in der Exchange-Verwaltungskonsole unterstützt Sie dabei, die richtige Namensliste in die Zertifikatanforderung aufzunehmen. Der Assistent fragt ab, für welche Dienste das Zertifikat eingesetzt wird und erstellt basierend auf den ausgewählten Diensten die Namen, die in das Zertifikat eingefügt werden müssen. Führen Sie den Zertifikat-Assistenten aus, wenn Sie die ersten Exchange 2010-Server bereitgestellt und festgelegt haben, welche Hostnamen für die verschiedenen Dienste in Ihrer Bereitstellung verwendet werden sollen. Im Idealfall müssen Sie den Zertifikat-Assistenten nur einmal pro Active Directory-Standort mit einer Exchange-Bereitstellung ausführen.

Statt sich darüber Sorgen zu machen, dass ein Hostname in der SAN-Liste des erworbenen Zertifikats fehlt, können Sie eine Zertifizierungsstelle wählen, die innerhalb einer Kulanzzeit ohne Aufpreis ein Zertifikat zurücknimmt und dasselbe Zertifikat mit einigen zusätzlichen Hostnamen erneut ausstellt.

Bewährte Methode: So wenige Hostnamen wie möglich

Zusätzlich dazu, so wenige Zertifikate wie möglich zu verwenden, sollten Sie auch die Anzahl der Hostnamen so gering wie möglich halten. So können Sie Geld sparen. Viele Zertifikatanbieter berechnen eine Gebühr basierend auf der Anzahl von Hostnamen in einem Zertifikat.

Um die Anzahl der erforderlichen Hostnamen und damit auch die Komplexität bei der Zertifikatverwaltung zu verringern, sollten Sie keine Hostnamen einzelner Server in die SANs Ihres Zertifikats einschließen.

Die Hostnamen, die Sie in Ihre Exchange-Zertifikate einschließen sollten, sind die Hostnamen, die von Clientanwendungen zur Verbindungsherstellung mit Exchange verwendet werden. In der nachfolgenden Liste werden typische Hostnamen aufgeführt, die für ein Unternehmen namens Contoso erforderlich wären:

• Mail.contoso.com   Dieser Hostname deckt die meisten Verbindungen zu Exchange ab, einschließlich Microsoft Office Outlook, Outlook-Webanwendung, Outlook Anywhere, Offlineadressbuch (OAB), Exchange-Webdienste, POP3, IMAP4, SMTP, Exchange-Systemsteuerung und ActiveSync.
• Autodiscover.contoso.com   Dieser Hostname wird von Clients verwendet, die die AutoErmittlung unterstützen, einschließlich Microsoft Office Outlook 2007 und höheren Versionen, Exchange ActiveSync und Exchange-Webdiensteclients.
• Legacy.contoso.com   Dieser Hostname ist in einem Koexistenzszenario mit Exchange Server 2003 oder Exchange 2007 erforderlich. Wenn Sie über Clients verfügen, die sowohl Postfächer auf einer Legacyversion von Exchange und Exchange 2010 verwenden, wird durch die Konfiguration eines Legacyhostnamens verhindert, dass die Benutzer beim Upgrade einen zweiten URL benötigen. Weitere Informationen zu Upgrade und Koexistenz finden Sie unter Upgrade von Exchange 2003 für den Clientzugriff und Upgrade von Exchange 2007 für den Clientzugriff.

Clienteinschränkungen

Verschiedene Exchange-Clients schränken die unterstützen Zertifikate ein. Diese Clients und die geltenden Beschränkungen werden nachfolgend zusammengefasst:

• Outlook auf Windows XP oder früheren Betriebssystemen   Die für Outlook Anywhere verwendete RPC-über-HTTP-Komponente von Windows erfordert, dass der SAN oder der allgemeine Name des Zertifikats mit dem für Outlook Anywhere konfigurierten Zertifikatprinzipalnamen übereinstimmt. Outlook 2007 und höhere Versionen verwenden die AutoErmittlung zum Abrufen dieses Zertifikatprinzipalnamens. Um diesen Wert auf Ihrem Exchange 2010-Clientzugriffsserver zu konfigurieren, verwenden Sie den Befehl Set-OutlookProvider mit dem Parameter-CertPrincipalName. Legen Sie diesen Parameter auf den externen Hostnamen fest, den Outlook-Clients zur Verbindungsherstellung mit Outlook Anywhere verwenden.
• Outlook-Versionen vor Outlook 2010 unterstützen keine SAN-Zertifikate für POP3- und IMAP4-Zugriff   Ein Hotfix für die SAN-Unterstützung steht in Outlook 2007 Service Pack 2 zur Verfügung. Das Hotfix finden Sie hier.
• Mobilgeräte   Einige Mobilgeräte, einschließlich von Geräten mit Windows Mobile 5.0 sowie einige Palm-Geräte, unterstützen keine Platzhalterzertifikate.