Digitale Zertifikate und SSL

Gilt für: Exchange Server 2013

Secure Sockets Layer (SSL) ist eine Methode zum Sichern der Kommunikation zwischen einem Client und einem Server. Für Exchange Server 2013 wird SSL verwendet, um die Kommunikation zwischen Dem Server und Clients zu sichern. Clients sind z. B. Mobiltelefone sowie Computer innerhalb und außerhalb des Netzwerks einer Organisation.

Wenn Sie Exchange 2013 installieren, wird die Clientkommunikation standardmäßig mit SSL verschlüsselt, wenn Sie Outlook Web App, Exchange ActiveSync und Outlook Anywhere verwenden.

SSL erfordert, dass Sie digitale Zertifikate verwenden. In diesem Thema werden die verschiedenen Arten von digitalen Zertifikaten und Informationen zum Konfigurieren von Exchange 2013 für die Verwendung dieser Arten von digitalen Zertifikaten zusammengefasst.

Ü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 Erklärung, die von einer Zertifizierungsstelle (CA) ausgestellt wird, die die Identität des Zertifikatinhabers angibt und es den Parteien ermöglicht, mithilfe der Verschlüsselung sicher zu kommunizieren.

Digitale Zertifikate führen folgende Aktionen aus:

  • Sie authentifizieren, dass ihre Inhaber (Personen, Websites und sogar Netzwerkressourcen wie Router) wirklich wer oder was sie für sich beanspruchen.

  • Sie schützen Daten, die online ausgetauscht werden, vor Diebstahl oder Manipulation.

Digitale Zertifikate können von einer vertrauenswürdigen Drittanbieter-Zertifizierungsstelle oder einer Windows Public Key Infrastructure (PKI) mithilfe von Zertifikatdiensten ausgestellt oder selbstsigniert werden. Jeder Zertifikattyp hat Vor- und Nachteile. Jede Art von digitalem Zertifikat ist manipulationssicher und kann nicht geschmiedet werden.

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

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. Die öffentlichen und privaten Schlüssel werden vom Client und vom Server verwendet, um die Daten zu verschlüsseln, bevor sie übertragen werden. Für Windows-basierte Benutzer, Computer und Dienste wird die Vertrauensstellung in eine Zertifizierungsstelle eingerichtet, wenn eine Kopie des Stammzertifikats im vertrauenswürdigen Stammzertifikatspeicher vorhanden ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Damit das Zertifikat gültig ist, darf das Zertifikat nicht widerrufen worden sein, und die Gültigkeitsdauer darf nicht abgelaufen sein.

Typen von Zertifikaten

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

Selbstsignierte Zertifikate

Wenn Sie Exchange 2013 installieren, wird automatisch ein selbstsigniertes Zertifikat auf den Postfachservern konfiguriert. Ein selbstsigniertes Zertifikat wird von der Anwendung signiert, von der es erstellt wurde. Der Betreff und der Name des Zertifikats stimmen überein. Der Aussteller und der Betreff sind im Zertifikat definiert. Dieses selbstsignierte Zertifikat wird verwendet, um die Kommunikation zwischen dem Clientzugriffsserver und dem Postfachserver zu verschlüsseln. Der Clientzugriffsserver vertraut dem selbstsignierten Zertifikat auf dem Postfachserver automatisch, sodass kein Drittanbieterzertifikat auf dem Postfachserver benötigt wird. Wenn Sie Exchange 2013 installieren, wird auch ein selbstsigniertes Zertifikat auf dem Clientzugriffsserver erstellt. Dieses selbstsignierte Zertifikat ermöglicht es einigen Clientprotokollen, SSL für ihre Kommunikation zu verwenden. Exchange ActiveSync und Outlook Web App können eine SSL-Verbindung unter Verwendung eines selbstsignierten Zertifikats herstellen. Outlook Anywhere funktioniert nicht mit einem selbstsignierten Zertifikat auf dem Clientzugriffsserver. Selbstsignierte Zertifikate müssen manuell in den vertrauenswürdigen Stammzertifikatspeicher auf dem Clientcomputer oder mobilen Gerät kopiert werden. Wenn ein Client über SSL eine Verbindung mit einem Server herstellt und der Server ein selbstsigniertes Zertifikat vorlegt, wird der Client aufgefordert, zu überprüfen, ob das Zertifikat von einer vertrauenswürdigen Behörde ausgestellt wurde. Der Client muss der ausstellenden Behörde explizit vertrauen. Wenn der Client die Vertrauensstellung bestätigt, kann die SSL-Kommunikation fortgesetzt werden.

Hinweis

Standardmäßig ist das auf dem Postfachserver oder auf den Servern installierte digitale Zertifikat ein selbstsigniertes Zertifikat. Sie müssen das selbstsignierte Zertifikat auf den Postfachservern in Ihrer Organisation nicht durch ein vertrauenswürdiges Drittanbieterzertifikat ersetzen. Der Clientzugriffsserver vertraut automatisch dem selbstsignierten Zertifikat auf dem Postfachserver, und für Zertifikate auf dem Postfachserver ist keine andere Konfiguration erforderlich.

Häufig entscheiden sich kleine Organisationen, kein Drittanbieterzertifikat zu verwenden oder keine eigene PKI zu installieren, um ihre eigenen Zertifikate auszustellen. Sie treffen diese Entscheidung möglicherweise, weil diese Lösungen zu teuer sind, weil ihre Administratoren die Erfahrung und das Wissen zum Erstellen ihrer eigenen Zertifikathierarchie oder aus beiden Gründen nicht besitzen. Die Kosten sind minimal, und die Einrichtung ist einfach, wenn Sie selbstsignierte Zertifikate verwenden. Es ist jedoch viel schwieriger, eine Infrastruktur für die Verwaltung des Zertifikatlebenszyklus, die Erneuerung, die Vertrauensverwaltung und den Widerruf einzurichten, wenn Sie selbstsignierte Zertifikate verwenden.

Windows Public Key-Infrastrukturzertifikate

Der zweite Zertifikattyp ist ein Windows PKI-generiertes Zertifikat. Eine PKI ist ein System von digitalen Zertifikaten, Zertifizierungsstellen und Registrierungsstellen (RAs), die die Gültigkeit jeder Partei überprüfen und authentifizieren, die an einer elektronischen Transaktion beteiligt ist, indem sie öffentliche Schlüsselkryptografie verwendet. Wenn Sie eine PKI in einer Organisation implementieren, die Active Directory verwendet, stellen Sie eine Infrastruktur für die Verwaltung des Zertifikatlebenszyklus, die Erneuerung, die Vertrauensverwaltung und die Sperrung bereit. Bei der Bereitstellung von Servern und Infrastruktur zum Erstellen und Verwalten Windows PKI-generierten Zertifikaten sind jedoch einige zusätzliche Kosten verbunden.

Zertifikatdienste sind erforderlich, um eine Windows PKI bereitzustellen und können über Add or Remove Programs in Systemsteuerung installiert werden. Sie können die Zertifikatdienste auf jedem Server in der Domäne installieren.

Wenn Sie Zertifikate von einer in eine Domäne eingebundenen Windows Ca beziehen, können Sie die Zertifizierungsstelle verwenden, um Zertifikate anzufordern oder zu signieren, die sie auf Ihren eigenen Servern oder Computern in Ihrem Netzwerk ausstellen. Auf diese Weise können Sie eine PKI verwenden, die einem Zertifikatdrittanbieter ähnelt, jedoch weniger kostspielig ist. Diese PKI-Zertifikate können nicht öffentlich bereitgestellt werden, wie es andere Typen von Zertifikaten sein können. Wenn jedoch eine PKI-Zertifizierungsstelle das Zertifikat des Antragstellers mithilfe des privaten Schlüssels signiert, wird der Antragsteller überprüft. 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 Anfordererzertifikats verwenden und den Anforderer authentifizieren.

Die Schritte zum Bereitstellen eines PKI-generierten Zertifikats ähneln denen, die für die Bereitstellung eines selbstsignierten Zertifikats erforderlich sind. Sie müssen weiterhin eine Kopie des vertrauenswürdigen Stammzertifikats von der PKI in den vertrauenswürdigen Stammzertifikatspeicher der Computer oder mobilen Geräte installieren, auf denen Sie eine SSL-Verbindung mit Microsoft Exchange herstellen möchten.

Mit einer Windows PKI können Organisationen ihre eigenen Zertifikate veröffentlichen. Clients können Zertifikate von einer Windows PKI im internen Netzwerk anfordern und empfangen. Die Windows PKI kann Zertifikate verlängern oder widerrufen.

Vertrauenswürdige Zertifikate von Drittanbietern

Zertifikate von Drittanbietern oder kommerziellen Unternehmen sind Zertifikate, die von einem Drittanbieter oder einer kommerziellen Zertifizierungsstelle generiert und dann erworben werden, damit Sie sie auf Ihren Netzwerkservern verwenden können. Ein Problem mit selbstsignierten und PKI-basierten Zertifikaten besteht darin, dass Sie sicherstellen müssen, dass Sie das Zertifikat in den vertrauenswürdigen Stammzertifikatspeicher auf Clientcomputern und -geräten importieren, da das Zertifikat nicht automatisch vom Clientcomputer oder mobilen Gerät als vertrauenswürdig eingestuft wird. Zertifikate von Drittanbietern oder kommerziellen Unternehmen haben dieses Problem nicht. 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 vertrauenswürdig ist, ist das Zertifikat ebenfalls vertrauenswürdig. Die Verwendung von Drittanbieterzertifikaten vereinfacht die Bereitstellung erheblich.

Für größere Organisationen oder Organisationen, die Zertifikate öffentlich bereitstellen müssen, besteht die beste Lösung darin, ein Drittanbieter- oder kommerzielles Zertifikat zu verwenden, obwohl dem Zertifikat Kosten zugeordnet sind. Kommerzielle Zertifikate sind möglicherweise nicht die beste Lösung für kleine und mittlere Organisationen, und Sie können sich entscheiden, eine der anderen verfügbaren Zertifikatoptionen zu verwenden.

Auswählen eines Zertifikattyps

Wenn Sie den Typ des zu installierenden Zertifikats auswählen, müssen Sie mehrere Punkte berücksichtigen. Ein Zertifikat muss signiert sein, damit es gültig ist. Es kann selbstsigniert oder von einer Zertifizierungsstelle signiert werden. Ein selbstsigniertes Zertifikat weist Einschränkungen auf. Beispielsweise lassen nicht alle mobilen Geräte einen Benutzer ein digitales Zertifikat im vertrauenswürdigen Stammzertifikatspeicher installieren. Die Möglichkeit, Zertifikate auf einem mobilen Gerät zu installieren, hängt vom Hersteller des mobilen Geräts und dem Mobilfunkanbieter ab. Einige Hersteller und Anbieter mobiler Dienste deaktivieren den Zugriff auf den vertrauenswürdigen Stammzertifikatspeicher. In diesem Fall können weder ein selbstsigniertes Zertifikat noch ein Zertifikat einer Windows PKI-Zertifizierungsstelle auf dem mobilen Gerät installiert werden.

Standardzertifikate Exchange

Standardmäßig installiert Exchange ein selbstsigniertes Zertifikat sowohl auf dem Clientzugriffsserver als auch auf dem Postfachserver, sodass die gesamte Netzwerkkommunikation verschlüsselt ist. Zum Verschlüsseln der gesamten Netzwerkkommunikation muss jeder Exchange Server über ein X.509-Zertifikat verfügen, das verwendet werden kann. Sie sollten dieses selbstsignierte Zertifikat auf dem Clientzugriffsserver durch ein Zertifikat ersetzen, das von Ihren Clients automatisch als vertrauenswürdig eingestuft wird.

"Selbstsigniert" bedeutet, dass ein Zertifikat nur vom Exchange Server selbst erstellt und signiert wurde. Da es nicht von einer allgemein vertrauenswürdigen Zertifizierungsstelle erstellt und signiert wurde, wird das selbstsignierte Standardzertifikat von keiner Software außer anderen Exchange Servern in derselben Organisation als vertrauenswürdig eingestuft. Das Standardzertifikat ist für alle Exchange Dienste aktiviert. Es hat einen alternativen Antragstellernamen (SAN), der dem Servernamen des Exchange Servers entspricht, auf dem er installiert ist. Es enthält außerdem eine Liste von SANs, die sowohl den Servernamen als auch den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servers enthalten.

Obwohl andere Exchange Server in Ihrer Exchange Organisation diesem Zertifikat automatisch vertrauen, vertrauen Clients wie Webbrowser, Outlook Clients, Mobiltelefone und andere E-Mail-Clients nicht automatisch dem Zertifikat. Erwägen Sie daher, dieses Zertifikat durch ein vertrauenswürdiges Drittanbieterzertifikat auf Ihren Exchange Clientzugriffsservern zu ersetzen. Wenn Sie über eine eigene interne PKI verfügen und alle Ihre Clients dieser Entität vertrauen, können Sie auch Zertifikate verwenden, die Sie selbst ausstellen.

Zertifikatanforderungen nach Dienst

Zertifikate werden in Exchange für mehrere Dinge verwendet. Die meisten Kunden verwenden Zertifikate auch auf mehr als einem Exchange Server. Im Allgemeinen gilt: Je weniger Zertifikate Sie besitzen, desto einfacher wird die Zertifikatverwaltung.

IIS

Alle folgenden Exchange Dienste verwenden dasselbe Zertifikat auf einem bestimmten Exchange Clientzugriffsserver:

  • Outlook Web App

  • Exchange-Verwaltungskonsole

  • Exchange-Webdienste

  • Exchange ActiveSync

  • Outlook Anywhere

  • AutoErmittlung

  • Outlook Adressbuchverteilung

Da einer Website nur ein einzelnes Zertifikat zugeordnet werden kann und alle diese Dienste standardmäßig unter einer einzigen Website angeboten werden, müssen sich alle Namen, die Clients dieser Dienste verwenden, im Zertifikat befinden (oder unter einen Platzhalternamen im Zertifikat fallen).

POP/IMAP

Zertifikate, die für POP oder IMAP verwendet werden, können separat vom Zertifikat angegeben werden, das für IIS verwendet wird. Um die Verwaltung zu vereinfachen, empfehlen wir jedoch, den POP- oder IMAP-Dienstnamen in Ihr IIS-Zertifikat aufzunehmen und für alle diese Dienste ein einzelnes Zertifikat zu verwenden.

SMTP

Für jeden von Ihnen konfigurierten Empfangsconnector kann ein separates Zertifikat verwendet werden. Das Zertifikat muss den Namen enthalten, den SMTP-Clients (oder andere SMTP-Server) verwenden, um diesen Connector zu erreichen. Um die Zertifikatverwaltung zu vereinfachen, sollten Sie alle Namen, für die Sie TLS-Datenverkehr unterstützen müssen, in ein einziges Zertifikat einschließen.

Digitale Zertifikate und Proxying

Proxying ist die Methode, mit der ein Server Clientverbindungen an einen anderen Server sendet. Im Fall von Exchange 2013 geschieht dies, wenn der Clientzugriffsserver eine eingehende Clientanforderung an den Postfachserver weitergibt, der die aktive Kopie des Postfachs des Clients enthält.

Bei Proxyanforderungen für Clientzugriffsserver wird SSL für die Verschlüsselung, aber nicht für die Authentifizierung verwendet. Das selbstsignierte Zertifikat auf dem Postfachserver verschlüsselt den Datenverkehr zwischen dem Clientzugriffsserver und dem Postfachserver.

Reverseproxys und Zertifikate

Viele Exchange-Bereitstellungen verwenden Reverseproxys, um Exchange Dienste im Internet zu veröffentlichen. Reverseprxies können so konfiguriert werden, dass die SSL-Verschlüsselung beendet wird, der Datenverkehr auf dem Server überprüft und dann ein neuer SSL-Verschlüsselungskanal von den Reverseproxyservern zu den Exchange Servern geöffnet wird, die dahinter stehen. Dies wird als SSL-Überbrückung bezeichnet. Eine weitere Möglichkeit zum Konfigurieren der Reverseproxyserver besteht darin, die SSL-Verbindungen direkt zu den Exchange Servern hinter den Reverseproxyservern durchgehen zu lassen. Bei beiden Bereitstellungsmodellen stellen die Clients im Internet eine Verbindung mit dem Reverseproxyserver her, indem sie einen Hostnamen für Exchange Zugriff verwenden, z. B. mail.contoso.com. Anschließend stellt der Reverseproxyserver eine Verbindung mit Exchange unter verwendung eines anderen Hostnamens her, z. B. den Computernamen des Exchange Clientzugriffsservers. Sie müssen den Computernamen des Exchange Clientzugriffsservers nicht in Ihr Zertifikat einschließen, da die meisten gängigen Reverseproxyserver den ursprünglichen Hostnamen, der vom Client verwendet wird, mit dem internen Hostnamen des Exchange Clientzugriffsservers abgleichen können.

SSL und split DNS

Split DNS ist eine Technologie, mit der Sie verschiedene IP-Adressen für denselben Hostnamen konfigurieren können, je nachdem, woher die dns-Anforderung stammt. Dies wird auch als split-horizon DNS, split-view DNS oder split-brain DNS bezeichnet. Split DNS kann Ihnen dabei helfen, die Anzahl der Hostnamen zu verringern, die Sie für Exchange verwalten müssen, indem Ihre Clients die Verbindung mit Exchange über denselben Hostnamen herstellen können, unabhängig davon, ob sie eine Verbindung über das Internet oder über das Intranet herstellen. Split DNS ermöglicht Anforderungen, die aus dem Intranet stammen, eine andere IP-Adresse als Anforderungen, die aus dem Internet stammen.

Split DNS ist in einer kleinen Exchange Bereitstellung in der Regel nicht erforderlich, da Benutzer unabhängig vom Intranet oder aus dem Internet auf denselben DNS-Endpunkt zugreifen können. Bei größeren Bereitstellungen führt diese Konfiguration jedoch zu einer zu hohen Auslastung des ausgehenden Internetproxyservers und des Reverseproxyservers. Konfigurieren Sie für größere Bereitstellungen geteiltes DNS so, dass beispielsweise externe Benutzer auf mail.contoso.com und interne Benutzer auf internal.contoso.com zugreifen. Die Verwendung von geteiltem DNS für diese Konfiguration stellt sicher, dass Ihre Benutzer nicht daran denken müssen, unterschiedliche Hostnamen zu verwenden, je nachdem, wo sie sich befinden.

Windows PowerShell-Remotesitzungen

Kerberos-Authentifizierung und Kerberos-Verschlüsselung werden für den Remotezugriff Windows PowerShell sowohl über das Exchange Admin Center (EAC) als auch über die Exchange-Verwaltungsshell verwendet. Daher müssen Sie Ihre SSL-Zertifikate nicht für die Verwendung mit Remote-Windows 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 in Bezug auf nicht vertrauenswürdige Zertifikate erhalten, muss das zertifikat, das von Ihrem Exchange Server verwendet wird, von jemandem ausgestellt werden, dem der Client vertraut. Obwohl die meisten Clients so konfiguriert werden können, dass sie jedem Zertifikat- oder Zertifikatherausgeber vertrauen, ist es einfacher, ein vertrauenswürdiges Drittanbieterzertifikat auf Ihrem Exchange-Server zu verwenden. Dies liegt daran, dass die meisten Clients ihren Stammzertifikaten bereits vertrauen. Es gibt mehrere Zertifikatherausgeber von Drittanbietern, die Zertifikate anbieten, die speziell für Exchange konfiguriert sind. Sie können das EAC verwenden, um Zertifikatanforderungen zu generieren, die mit den meisten Zertifikatherausgebern funktionieren.

Auswählen einer Zertifizierungsstelle

Eine Zertifizierungsstelle ist ein Unternehmen, das Zertifikate ausstellt und sicherstellt. Clientsoftware (z. B. Browser wie Microsoft Internet Explorer oder Betriebssysteme wie Windows oder Mac OS) verfügt über eine integrierte Liste von vertrauenswürdigen CAs. Diese Liste kann in der Regel so konfiguriert werden, dass CAs hinzugefügt und entfernt werden, aber diese Konfiguration ist oft umständlich. Verwenden Sie die folgenden Kriterien, wenn Sie eine Zertifizierungsstelle auswählen, bei der Sie Ihre Zertifikate kaufen möchten:

  • Stellen Sie sicher, dass die Zertifizierungsstelle von der Clientsoftware (Betriebssysteme, Browser und Mobiltelefone) als vertrauenswürdig eingestuft wird, die eine Verbindung mit Ihren Exchange Servern herstellt.

  • Wählen Sie eine Zertifizierungsstelle aus, die besagt, dass sie "Unified Communications-Zertifikate" für die Verwendung mit Exchange Server unterstützt.

  • Stellen Sie sicher, dass die Zertifizierungsstelle die Arten von Zertifikaten unterstützt, die Sie verwenden werden. Erwägen Sie die Verwendung von SAN-Zertifikaten (Subject Alternative Name). Nicht alle Zertifizierungsstellen unterstützen SAN-Zertifikate, und andere Zertifizierungsstellen unterstützen nicht so viele Hostnamen, wie Sie möglicherweise benötigen.

  • Stellen Sie sicher, dass Sie mit der Lizenz, die Sie für die Zertifikate kaufen, das Zertifikat auf der Anzahl der Server platzieren können, die Sie verwenden möchten. Bei einigen Zertifizierungsstellen können Sie nur ein Zertifikat auf einem Server ablegen.

  • Vergleichen Sie die Zertifikatpreise zwischen Zertifizierungsstellen.

Bewährte Methode: Verwenden von SAN-Zertifikaten

Je nachdem, wie Sie die Dienstnamen in Ihrer Exchange Bereitstellung konfigurieren, benötigt Ihr Exchange Server möglicherweise ein Zertifikat, das mehrere Domänennamen darstellen kann. Obwohl ein Platzhalterzertifikat, z. B. eines für *.contoso.com, dieses Problem beheben kann, sind viele Kunden mit den Sicherheitsauswirkungen der Verwaltung eines Zertifikats, das für jede Unterdomäne verwendet werden kann, unbequem. Eine sicherere Alternative besteht darin, jede der erforderlichen Domänen als SANs im Zertifikat auflisten. Standardmäßig wird dieser Ansatz verwendet, wenn Zertifikatanforderungen von Exchange generiert werden.

Bewährte Methode: Verwenden des Exchange Zertifikat-Assistenten zum Anfordern von Zertifikaten

Es gibt viele Dienste in Exchange, die Zertifikate verwenden. Ein häufiger Fehler beim Anfordern von Zertifikaten besteht darin, die Anforderung zu stellen, ohne den richtigen Satz von Dienstnamen einzubestellen. Der Zertifikat-Assistent im Exchange Admin Center hilft Ihnen, die richtige Liste der Namen in die Zertifikatanforderung einzuschließen. Mit dem Assistenten können Sie angeben, mit welchen Diensten das Zertifikat arbeiten muss, und basierend auf den ausgewählten Diensten die Namen enthalten, die Sie im Zertifikat haben müssen, damit es mit diesen Diensten verwendet werden kann. Führen Sie den Zertifikat-Assistenten aus, wenn Sie Ihre anfängliche Gruppe von Exchange 2013-Servern bereitgestellt und ermittelt haben, welche Hostnamen für die verschiedenen Dienste für Ihre Bereitstellung verwendet werden sollen. Im Idealfall müssen Sie den Zertifikat-Assistenten nur einmal für jeden Active Directory-Standort ausführen, an dem Sie Exchange bereitstellen.

Anstatt sich Gedanken darüber zu machen, einen Hostnamen in der SAN-Liste des erworbenen Zertifikats zu vergessen, können Sie eine Zertifizierungsstelle verwenden, die kostenlos eine Nachfrist bietet, in der Sie ein Zertifikat zurückgeben und dasselbe neue Zertifikat mit ein paar zusätzlichen Hostnamen anfordern können.

Bewährte Methode: Verwenden Sie so wenige Hostnamen wie möglich

Sie sollten nicht nur so wenige Zertifikate wie möglich verwenden, sondern auch möglichst wenige Hostnamen verwenden. Diese Praxis kann Geld sparen. Viele Zertifikatanbieter berechnen eine Gebühr basierend auf der Anzahl der Hostnamen, die Sie Ihrem Zertifikat hinzufügen.

Der wichtigste Schritt, den Sie unternehmen können, um die Anzahl der Hostnamen zu verringern, die Sie haben müssen, und daher die Komplexität Ihrer Zertifikatverwaltung besteht darin, keine einzelnen Serverhostnamen in die alternativen Antragstellernamen Ihres Zertifikats aufzunehmen.

Die Hostnamen, die Sie in Ihre Exchange Zertifikate einschließen müssen, sind die Hostnamen, die von Clientanwendungen zum Herstellen einer Verbindung mit Exchange verwendet werden. Es folgt eine Liste typischer Hostnamen, die für ein Unternehmen namens Contoso erforderlich wären:

  • Mail.contoso.com: Dieser Hostname deckt die meisten Verbindungen mit Exchange ab, einschließlich Microsoft Outlook, Outlook Web App, Outlook Anywhere, dem Offlineadressbuch, Exchange Webdiensten, 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 neueren Versionen, Exchange ActiveSync und Exchange Webdienstclients.

  • Legacy.contoso.com: Dieser Hostname ist in einem Koexistenzszenario mit Exchange 2007 und Exchange 2013 erforderlich. Wenn Sie Clients mit Postfächern auf Exchange 2007 und Exchange 2013 haben, verhindert das Konfigurieren eines älteren Hostnamens, dass Ihre Benutzer während des Upgradeprozesses eine zweite URL erlernen müssen.

Grundlegendes zu Platzhalterzertifikaten

Ein Platzhalterzertifikat wurde entwickelt, um eine Domäne und mehrere Unterdomänen zu unterstützen. Beispielsweise führt das Konfigurieren eines Platzhalterzertifikats für *.contoso.com zu einem Zertifikat, das für mail.contoso.com, web.contoso.com und autodiscover.contoso.com funktioniert.