Digitale Zertifikate und SSL

  • Artikel

Gilt für: Exchange Server 2013

Secure Sockets Layer (SSL) ist eine Methode zum Schützen der Kommunikation zwischen einem Client und einem Server. Für Exchange Server 2013 wird SSL verwendet, um die Kommunikation zwischen dem Server und den Clients zu schützen. 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 bürgt und den Parteien die sichere Kommunikation mittels Verschlüsselung ermöglicht.

Digitale Zertifikate führen folgende Aktionen aus:

  • Sie authentifizieren, dass ihre Inhaber (Personen, Websites und sogar Netzwerkressourcen wie Router) wirklich wer oder was sie zu sein behaupten.

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

Digitale Zertifikate können von einer vertrauenswürdigen Drittanbieterzertifizierungsstelle oder einer Windows-PKI (Public Key-Infrastruktur) mithilfe von Zertifikatdiensten ausgestellt werden, oder sie können selbstsigniert sein. Jeder Zertifikattyp hat Vor- und Nachteile. Jede Art von digitalem Zertifikat ist manipulationssicher und kann nicht gefälscht werden.

Zertifikate können für verschiedene Zwecke ausgestellt werden. Zu diesen Verwendungen gehören die Webbenutzerauthentifizierung, die Webserverauthentifizierung, S/MIME (Secure/Multipurpose Internet Mail Extensions), 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 vor der Übertragung zu verschlüsseln. Für Windows-basierte Benutzer, Computer und Dienste wird eine Vertrauensstellung in einer Zertifizierungsstelle hergestellt, 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.

Arten 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, die es erstellt hat. Der Antragsteller und der Name des Zertifikats stimmen überein. Der Aussteller und der Antragsteller 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 auf dem Postfachserver kein Drittanbieterzertifikat erforderlich ist. 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 vorstellt, wird der Client aufgefordert, zu überprüfen, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle 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 digitale Zertifikat, das auf dem Postfachserver oder -servern installiert ist, 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 ihre eigene PKI nicht zu installieren, um ihre eigenen Zertifikate auszustellen. Sie können diese Entscheidung treffen, weil diese Lösungen zu teuer sind, weil ihre Administratoren nicht über die Erfahrung und das Wissen verfügen, um eine eigene Zertifikathierarchie zu erstellen, oder aus beiden Gründen. 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, Erneuerung, Vertrauensverwaltung und Sperrung von Zertifikaten einzurichten, wenn Sie selbstsignierte Zertifikate verwenden.

Public Key-Infrastrukturzertifikate für Windows

Der zweite Zertifikattyp ist ein von Windows PKI generiertes Zertifikat. Eine PKI ist ein System aus digitalen Zertifikaten, Zertifizierungsstellen und Registrierungsstellen (RAs), die die Gültigkeit jeder Partei, die an einer elektronischen Transaktion beteiligt ist, mithilfe von Kryptografie mit öffentlichem Schlüssel überprüfen und authentifizieren. Wenn Sie eine PKI in einer Organisation implementieren, die Active Directory verwendet, stellen Sie eine Infrastruktur für die Verwaltung des Zertifikatlebenszyklus, die Verlängerung, die Vertrauensverwaltung und die Sperrung bereit. Es fallen jedoch einige zusätzliche Kosten für die Bereitstellung von Servern und Infrastrukturen zum Erstellen und Verwalten von Windows PKI-generierten Zertifikaten an.

Zertifikatdienste sind für die Bereitstellung einer Windows-PKI erforderlich und können über Software 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-Zertifizierungsstelle erhalten, können Sie die Zertifizierungsstelle verwenden, um Zertifikate anzufordern oder zu signieren, die auf Ihren eigenen Servern oder Computern in Ihrem Netzwerk ausgestellt werden. Auf diese Weise können Sie eine PKI verwenden, die einem Zertifikatdrittanbieter ähnelt, jedoch weniger kostspielig ist. Diese PKI-Zertifikate können nicht wie andere Arten von Zertifikaten öffentlich bereitgestellt werden. Wenn jedoch eine PKI-Zertifizierungsstelle das Zertifikat des Anforderers mit dem privaten Schlüssel signiert, wird der Anforderer ü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 von der 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 aus der PKI im vertrauenswürdigen Stammzertifikatspeicher der Computer oder mobilen Geräte installieren, die eine SSL-Verbindung mit Microsoft Exchange herstellen können sollen.

Eine Windows-PKI ermöglicht Es Organisationen, ihre eigenen Zertifikate zu 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 kommerzielle Zertifikate sind Zertifikate, die von einer drittanbieter- oder kommerziellen Zertifizierungsstelle generiert und dann für Die Verwendung auf Ihren Netzwerkservern erworben werden. Ein Problem bei 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 müssen, da das Zertifikat nicht automatisch vom Clientcomputer oder mobilen Gerät als vertrauenswürdig eingestuft wird. Bei Zertifikaten von Drittanbietern oder kommerziellen Zertifikaten gibt es 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, wird auch das Zertifikat als vertrauenswürdig eingestuft. 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 mit dem Zertifikat Kosten verbunden 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. Sie kann selbstsigniert oder von einer Zertifizierungsstelle signiert werden. Für ein selbstsigniertes Zertifikat gelten Einschränkungen. Beispielsweise können Benutzer nicht auf allen mobilen Geräten ein digitales Zertifikat im Speicher für vertrauenswürdige Stammzertifikate 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 Mobilfunkanbieter deaktivieren den Zugriff auf den vertrauenswürdigen Stammzertifikatspeicher. In diesem Fall kann weder ein selbstsigniertes Zertifikat noch ein Zertifikat von einer Windows-PKI-Zertifizierungsstelle auf dem mobilen Gerät installiert werden.

Exchange-Standardzertifikate

Standardmäßig installiert Exchange ein selbstsigniertes Zertifikat sowohl auf dem Clientzugriffsserver als auch auf dem Postfachserver, sodass die gesamte Netzwerkkommunikation verschlüsselt wird. Zum Verschlüsseln der gesamten Netzwerkkommunikation muss jeder Exchange-Server über ein X.509-Zertifikat verfügen, das er verwenden 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 mit Ausnahme anderer Exchange-Server in derselben Organisation als vertrauenswürdig eingestuft. Das Standardzertifikat ist für alle Exchange-Dienste aktiviert. Es verfügt über einen alternativen Antragstellernamen (Subject Alternative Name, SAN), der dem Servernamen des Exchange-Servers entspricht, auf dem es installiert ist. Außerdem enthält sie eine Liste von SANs, die sowohl den Servernamen als auch den vollqualifizierten Domänennamen (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 neben externen E-Mail-Servern nicht automatisch. 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 für verschiedene Dinge in Exchange verwendet. Die meisten Kunden verwenden zertifikate auch auf mehreren Exchange-Servern. Im Allgemeinen wird die Zertifikatverwaltung umso einfacher, je weniger Zertifikate Sie besitzen.

IIS

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

  • Outlook Web App

  • Exchange Admin Center (EAC)

  • 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 auf einer einzelnen Website angeboten werden, müssen alle Namen, die clients dieser Dienste verwenden, im Zertifikat enthalten sein (oder unter einen Wildcardnamen im Zertifikat fallen).

POP/IMAP

Zertifikate, die für POP oder IMAP verwendet werden, können getrennt von dem Zertifikat angegeben werden, das für IIS verwendet wird. Zur Vereinfachung der Verwaltung empfiehlt es sich jedoch, den POP- oder IMAP-Dienstnamen in Ihr IIS-Zertifikat aufzunehmen und ein einzelnes Zertifikat für alle diese Dienste zu verwenden.

SMTP

Für jeden empfangsconnector, den Sie konfigurieren, 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 einzelnes 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 sendet, der die aktive Kopie des Clientpostfachs enthält.

Bei Proxyanforderungen von Clientzugriffsservern 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. Reverseproxys können so konfiguriert werden, dass sie die SSL-Verschlüsselung beenden, den Datenverkehr auf dem Server überprüfen und dann einen neuen SSL-Verschlüsselungskanal von den Reverseproxyservern zu den exchange-Servern öffnen, die sich dahinter befinden. Dies wird als SSL-Bridging bezeichnet. Eine weitere Möglichkeit zum Konfigurieren der Reverseproxyserver besteht darin, die SSL-Verbindungen direkt an die Exchange-Server hinter den Reverseproxyservern zu übergeben. Bei beiden Bereitstellungsmodellen stellen die Clients im Internet eine Verbindung mit dem Reverseproxyserver her, indem sie einen Hostnamen für den Exchange-Zugriff verwenden, z. B. mail.contoso.com. Anschließend stellt der Reverseproxyserver eine Verbindung mit Exchange her, indem er einen anderen Hostnamen verwendet, z. B. den Computernamen des Exchange-Clientzugriffsservers. Sie müssen den Computernamen des Exchange-Clientzugriffsservers nicht in Ihr Zertifikat einschließen, da die häufigsten Reverseproxyserver den ursprünglichen Hostnamen, der vom Client verwendet wird, mit dem internen Hostnamen des Exchange-Clientzugriffsservers übereinstimmen können.

SSL und Geteiltes DNS

Split DNS ist eine Technologie, mit der Sie unterschiedliche IP-Adressen für denselben Hostnamen konfigurieren können, je nachdem, woher die ursprüngliche DNS-Anforderung stammt. Dies wird auch als Split-Horizon-DNS, Split-View-DNS oder Split-Brain-DNS bezeichnet. Split DNS kann Ihnen helfen, die Anzahl der Hostnamen zu reduzieren, die Sie für Exchange verwalten müssen, indem Sie Ihren Clients erlauben, über denselben Hostnamen eine Verbindung mit Exchange herzustellen, unabhängig davon, ob sie eine Verbindung über das Internet oder über das Intranet herstellen. Split DNS ermöglicht es Anforderungen, die aus dem Intranet stammen, eine andere IP-Adresse zu empfangen als Anforderungen, die aus dem Internet stammen.

Split DNS ist in einer kleinen Exchange-Bereitstellung in der Regel nicht erforderlich, da Benutzer auf denselben DNS-Endpunkt zugreifen können, unabhängig davon, ob sie aus dem Intranet oder dem Internet stammen. Bei größeren Bereitstellungen führt diese Konfiguration jedoch zu einer zu hohen Auslastung ihres ausgehenden Internetproxyservers und Ihres Reverseproxyservers. Konfigurieren Sie für größere Bereitstellungen geteiltes DNS, sodass z. B. 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, je nachdem, wo sie sich befinden, unterschiedliche Hostnamen zu verwenden.

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 einer Person ausgestellt werden, der der Client vertraut. Obwohl die meisten Clients so konfiguriert werden können, dass sie jedem Zertifikat oder Zertifikataussteller 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 Zertifikataussteller von Drittanbietern, die speziell für Exchange konfigurierte Zertifikate anbieten. Sie können das EAC verwenden, um Zertifikatanforderungen zu generieren, die mit den meisten Zertifikatausstellern funktionieren.

Auswählen einer Zertifizierungsstelle

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

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

  • Wählen Sie eine Zertifizierungsstelle aus, die angibt, 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 Die Lizenz, die Sie für die Zertifikate erwerben, es Ihnen ermöglicht, das Zertifikat auf der Anzahl der Server zu platzieren, 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. 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, unbehagen. Eine sicherere Alternative besteht darin, jede der erforderlichen Domänen als SANs im Zertifikat aufzulisten. Standardmäßig wird dieser Ansatz verwendet, wenn Zertifikatanforderungen von Exchange generiert werden.

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

Es gibt viele Dienste in Exchange, die Zertifikate verwenden. Ein häufiger Fehler beim Anfordern von Zertifikaten besteht darin, die Anforderung ohne Angabe des richtigen Satzes von Dienstnamen zu stellen. Der Zertifikat-Assistent im Exchange Admin Center hilft Ihnen dabei, die richtige Liste der Namen in die Zertifikatanforderung aufzunehmen. Mit dem Assistenten können Sie angeben, mit welchen Diensten das Zertifikat zusammenarbeiten muss. Basierend auf den ausgewählten Diensten enthält er die Namen, die im Zertifikat erforderlich sind, 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. Idealerweise 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 Karenzzeit anbietet, in der Sie ein Zertifikat zurückgeben und dasselbe neue Zertifikat mit einigen 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, aber auch so wenige Hostnamen wie möglich 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 ausführen können, um die Anzahl der Benötigten Hostnamen und damit die Komplexität Ihrer Zertifikatverwaltung zu reduzieren, 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. Im Folgenden finden Sie eine Liste der typischen 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, Offlineadressbuch, 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öher, Exchange ActiveSync und Exchange Web Services-Clients.

  • Legacy.contoso.com: Dieser Hostname ist in einem Koexistenzszenario mit Exchange 2007 und Exchange 2013 erforderlich. Wenn Sie Über Clients mit Postfächern unter Exchange 2007 und Exchange 2013 verfügen, verhindert die Konfiguration eines Legacyhostnamens, dass Ihre Benutzer während des Upgradevorgangs eine zweite URL abrufen müssen.

Grundlegendes zu Wildcardzertifikaten

Ein Platzhalterzertifikat ist für die Unterstützung einer Domäne und mehrerer Unterdomänen konzipiert. Das Konfigurieren eines Wildcardzertifikats für *.contoso.com führt beispielsweise zu einem Zertifikat, das für mail.contoso.com, web.contoso.com und autodiscover.contoso.com funktioniert.