Digitale Zertifikate und Verschlüsselung in Exchange 2016

[Dieses Thema gehört zur Vorabdokumentation und kann in künftigen Versionen geändert werden. Leere Themen wurden als Platzhalter hinzugefügt. Wenn Sie Feedback dazu haben, freuen wir uns über Ihre Nachricht. Senden Sie uns eine E-Mail an: ExchangeHelpFeedback@microsoft.com.]  

Gilt für:Exchange Server 2016

Informationen über SSL, TLS, Verschlüsselung und digitale Zertifikate in Exchange 2016.

Verschlüsselung und digitale Zertifikate sind wichtige Faktoren in jeder Organisation. Standardmäßig ist Exchange Server 2016 für die Verwendung von TLS (Transport Layer Security) zum Verschlüsseln der Kommunikation zwischen internen Exchange-Servern sowie zwischen Exchange-Diensten auf dem lokalen Server konfiguriert. Exchange-Administratoren müssen jedoch ihre Verschlüsselungsanforderungen für die Kommunikation mit internen und externen Clients (Computern und mobilen Geräten) sowie mit externen Messagingservern berücksichtigen.

noteHinweis:
Secure Sockets Layer (SSL) wird durch Transport Layer Security (TLS) als Protokoll ersetzt, das zum Verschlüsseln von Daten verwendet wird, die zwischen Computersystemen gesendet werden. Da die Begriffe „SSL“ und „TLS“ (ohne Versionen) so eng im Zusammenhang stehen, werden sie häufig synonym verwendet. Aufgrund dieser Ähnlichkeit wurden Verweise auf „SSL“ in Exchange-Themen, Exchange-Verwaltungskonsole und Exchange-Verwaltungsshell häufig so verwendet, dass sowohl die SSL- als auch die TLS-Protokolle enthalten sind. „SSL“ bezieht sich in der Regel nur dann auf das eigentliche SSL-Protokoll, wenn auch eine Version angegeben wird (z. B. SSL 3.0). Um zu erfahren, warum Sie das SSL-Protokoll deaktivieren und auf TLS umsteigen sollten, lesen Sie Schutz vor der Sicherheitsanfälligkeit von SSL 3.0.

In diesem Thema werden die verfügbaren Arten von Zertifikaten und die Standardkonfiguration für Zertifikate in Exchange beschrieben. Außerdem enthält es Vorschläge für zusätzliche Zertifikate, die Sie mit Exchange verwenden müssen.

Informationen zu den Verfahren, die für Zertifikate in Exchange 2016 erforderlich sind, finden Sie unter Zertifikatverfahren in Exchange 2016.

Inhalt

Übersicht über digitale Zertifikate

Zertifikate in Exchange

Zertifikatanforderungen für Exchange-Dienste

Bewährte Methoden für Exchange-Zertifikate

Eigenschaften der standardmäßigen selbstsignierten 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 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 bieten die folgenden Dienste:

  • Verschlüsselung   Sie schützen die ausgetauschten Daten vor Diebstahl und Manipulation.

  • Authentifizierung   Sie bestätigen, dass ihre Inhaber – Personen, Websites und sogar Netzwerkgeräte wie z. B. Router – wirklich das sind, was sie vorgeben zu sein. In der Regel ist die Authentifizierung unidirektional, wobei die Quelle die Identität des Ziels bestätigt, aber gegenseitige TLS-Authentifizierung ist ebenfalls möglich.

Zertifikate können für verschiedene Zwecke ausgestellt werden. Beispiel: zur Webbenutzerauthentifizierung, zur Webserverauthentifizierung, für S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol 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-Benutzer, -Computer und -Dienste wird eine Vertrauensstellung mit der Zertifizierungsstelle eingerichtet, wenn das Stammzertifikat im Speicher für vertrauenswürdige Stammzertifikate definiert ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Ein Zertifikat gilt als gültig, wenn es nicht gesperrt wurde (es ist nicht in der Zertifikatsperrliste (Certificate Revocation List, CRL) der Zertifizierungsstelle aufgeführt) und der Gültigkeitszeitraum nicht abgelaufen ist.

Die drei Haupttypen von digitalen Zertifikaten werden in der folgenden Tabelle beschrieben.

 

Typ Beschreibung Vorteile Nachteile

Selbstsigniertes Zertifikat

Das Zertifikat wird von der Anwendung signiert, die es erstellt hat.

Kosten (kostenlos).

Dem Zertifikat wird nicht automatisch von Clientcomputern und mobilen Geräten vertraut. Das Zertifikat muss dem Speicher für vertrauenswürdige Stammzertifikate auf allen Clientcomputern und Geräten manuell hinzugefügt werden, aber nicht alle mobilen Geräte lassen Änderungen am Speicher für vertrauenswürdige Stammzertifikate zu.

Nicht alle Dienste funktionieren mit selbstsignierten Zertifikaten.

Das Herstellen einer Infrastruktur für die Lebenszyklusverwaltung von Zertifikaten ist schwierig. Selbstsignierte Zertifikaten können z. B. nicht gesperrt werden.

Von einer internen Zertifizierungsstelle ausgestelltes Zertifikat

Das Zertifikat wird von einer Public Key-Infrastruktur (PKI) in Ihrer Organisation ausgestellt. Beispiel: Active Directory-Zertifikatdienste (AD CS). Weitere Informationen finden Sie unter Active Directory-Zertifikatdienste: Übersicht.

Ermöglicht Organisationen, eigene Zertifikate auszustellen.

Preisgünstiger als Zertifikate von einer kommerziellen Zertifizierungsstelle.

Höhere Komplexität beim Bereitstellen und Verwalten der PKI.

Dem Zertifikat wird nicht automatisch von Clientcomputern und mobilen Geräten vertraut. Das Zertifikat muss dem Speicher für vertrauenswürdige Stammzertifikate auf allen Clientcomputern und Geräten manuell hinzugefügt werden, aber nicht alle mobilen Geräte lassen Änderungen am Speicher für vertrauenswürdige Stammzertifikate zu.

Von einer kommerziellen Zertifizierungsstelle ausgestelltes Zertifikat

Das Zertifikat wird von einer vertrauenswürdigen gewerblichen Zertifizierungsstelle erworben.

Vereinfachte Zertifikatbereitstellung, da alle Clients, Geräte und Server automatisch den Zertifikaten vertrauen.

Kosten Sie müssen im Voraus planen, um die Anzahl der erforderlichen Zertifikate zu minimieren.

Um nachzuweisen, dass ein Zertifikatinhaber ist, wer er vorgibt zu sein, muss das Zertifikat den Zertifikatinhaber anderen Clients, Geräten oder Servern gegenüber genau identifizieren. Die drei grundlegenden Methoden dazu sind in der folgenden Tabelle beschrieben.

 

Methode Beschreibung Vorteile Nachteile

Abgleich mit dem Zertifikatantragsteller

Das Subject-Feld des Zertifikats enthält den allgemeinen Namen (Common Name, CN) des Hosts. Beispielsweise kann das Zertifikat, das für www.contoso.com ausgestellt wurde, für die Website https://www.contoso.com verwendet werden.

Kompatibel mit allen Clients, Geräten und Diensten.

Abschottung. Sperren des Zertifikats für einen Host wirkt sich nicht auf andere Hosts aus.

Anzahl erforderlicher Zertifikate. Sie können das Zertifikat nur für den angegebenen Host verwenden. Beispielsweise können Sie das Zertifikat www.contoso.com nicht für ftp.contoso.com verwenden, selbst wenn die Dienste auf demselben Server installiert sind.

Komplexität. Auf einem Webserver ist für jedes Zertifikat eine eigene IP-Adressbindung erforderlich.

Abgleich mit dem alternativen Zertifikatantragstellernamen (Subject Alternative Name, SAN)

Zusätzlich zum Subject-Feld enthält das Subject Alternative Name-Feld des Zertifikats eine Liste mit mehreren Hostnamen. Beispiel:

  • www.contoso.com

  • ftp.contoso.com

  • ftp.eu.fabirkam.net

Bequemlichkeit. Sie können das gleiche Zertifikat für mehrere Hosts in mehreren separaten Domänen verwenden.

Die meisten Clients, Geräte und Dienste unterstützen SAN-Zertifikate.

Überwachung und Sicherheit. Sie wissen genau, welche Hosts das SAN-Zertifikat verwenden können.

Mehr Planung erforderlich. Sie müssen die Liste der Hosts angeben, wenn Sie das Zertifikat erstellen.

Mangelnde Abschottung. Sie können Zertifikate nicht selektiv für einige der angegebenen Hosts widerrufen, ohne alle Hosts im Zertifikat zu beeinflussen.

Abgleich mit Platzhalterzertifikat

Das Subject-Feld des Zertifikats enthält den allgemeinen Namen als Platzhalterzeichen (*) plus eine einzelne Domäne oder Unterdomäne. Beispiel: *.contoso.com oder *.eu.contoso.com. Das Platzhalterzertifikat *.contoso.com kann verwendet werden für:

  • www.contoso.com

  • ftp.contoso.com

  • mail.contoso.com

Flexibilität. Sie müssen bei der Zertifikatanforderung keine Liste von Hosts angeben, und Sie können das Zertifikat auf jeder beliebigen Anzahl von Hosts verwenden, die Sie möglicherweise in der Zukunft benötigen.

Sie können Platzhalterzertifikate nicht mit anderen Domänen der obersten Ebene (Top-Level-Domains, TLDs) verwenden. Beispielsweise können Sie das Platzhalterzertifikat *.contoso.com nicht für Hosts auf *.contoso.net verwenden.

Sie können Platzhalterzertifikate nur für Hostnamen auf der Ebene des Platzhalters verwenden. Beispielsweise können Sie das Zertifikat *.contoso.com nicht für www.eu.contoso.com verwenden. Ebenso können Sie das Zertifikat *.eu.contoso.com nicht für www.uk.eu.contoso.com verwenden.

Ältere Clients, Geräte, Anwendungen oder Dienste unterstützen möglicherweise keine Platzhalterzertifikate.

Bei Zertifikaten für die erweiterte Überprüfung (Extended Validation, EV) können Platzhalter nicht verwendet werden.

Sorgfältige Überwachung und Kontrolle erforderlich. Wenn das Platzhalterzertifikat beschädigt wird, wirkt sich dies auf jeden Host in der angegebenen Domäne aus.

Zurück zum Seitenanfang

Wenn Sie Exchange 2016 auf einem Server installieren, werden standardmäßig zwei selbstsignierte Zertifikate von Exchange erstellt und installiert. Ein drittes selbstsigniertes Zertifikat wird von MicrosoftWindows für den Webverwaltungsdienst in Internetinformationsdienste (IIS) erstellt und installiert. Diese drei Zertifikate werden im Exchange-Verwaltungskonsole (EAC) und der Exchange-Verwaltungsshell angezeigt und werden in der folgenden Tabelle beschrieben:

 

Name Kommentare

Microsoft Exchange

Dieses selbstsignierte Zertifikat von Exchange weist die folgenden Merkmale auf:

  • Dem Zertifikat wird automatisch von allen anderen Exchange-Servern in der Organisation vertraut. Dazu gehören alle Edge-Transport-Server, die die Exchange-Organisation abonniert hat.

  • Das Zertifikat wird automatisch für alle Exchange-Dienste mit Ausnahme von Unified Messaging aktiviert und wird verwendet zur Verschlüsselung der internen Kommunikation zwischen Exchange-Servern, Exchange-Diensten auf demselben Computer und Clientverbindungen, die von den Clientzugriffsdiensten auf die Back-End-Dienste auf Postfachservern weitergeleitet werden.

  • Das Zertifikat wird automatisch für eingehende Verbindungen von externen SMTP-Messagingservern und für ausgehende Verbindungen zu externen SMTP-Messagingservern aktiviert. Diese Standardkonfiguration ermöglicht Exchange die Bereitstellung von opportunistischem TLS für alle eingehenden und ausgehenden SMTP-Verbindungen. Exchange versucht, die SMTP-Sitzung mit einem externen Messagingserver zu verschlüsseln, aber wenn der externe Server die TLS-Verschlüsselung nicht unterstützt, bleibt die Sitzung unverschlüsselt.

  • Das Zertifikat ermöglicht keine verschlüsselte Kommunikation mit internen oder externen Clients. Clients und Server vertrauen dem selbstsignierten Zertifikat von Exchange nicht, da es nicht in ihrem Zertifikatspeicher für vertrauenswürdige Stammzertifikate definiert ist.

Microsoft Exchange-Zertifikat für die Serverauthentifizierung

Dieses selbstsignierte Zertifikat von Exchange wird für die Server-zu-Server-Authentifizierung und Integration mithilfe von OAuth verwendet. Weitere Informationen finden Sie unter Planen der Exchange 2016-Integration in SharePoint und Skype for Business.

WMSVC

Dieses selbstsignierte Windows-Zertifikat wird vom Webverwaltungsdienst in IIS zum Aktivieren der Remoteverwaltung des Webservers und der ihm zugeordneten Websites und Anwendungen verwendet.

Wenn Sie dieses Zertifikat entfernen, kann der Webverwaltungsdienst nicht gestartet werden, falls kein gültiges Zertifikat ausgewählt ist. Wenn sich der Dienst in diesem Zustand befindet, können Sie möglicherweise keine Updates für Exchange installieren oder Exchange nicht vom Server deinstallieren. Weitere Informationen zum Beheben dieses Problems finden Sie unter Ereignis-ID 1007 – Authentifizierung des IIS-Webverwaltungsdiensts.

Die Eigenschaften dieser selbstsignierten Zertifikate sind im Abschnitt Eigenschaften der standardmäßigen selbstsignierten Zertifikaten beschrieben.

Dies sind die wichtigsten Probleme, die Sie bei Zertifikaten in Exchange berücksichtigen müssen:

  • Sie müssen das selbstsignierte Microsoft Exchange-Zertifikat nicht ersetzen, um den Netzwerkdatenverkehr zwischen Exchange-Servern und -Diensten in Ihrer Organisation zu verschlüsseln.

  • Sie benötigen zusätzliche Zertifikate zum Verschlüsseln von Verbindungen mit Exchange-Servern von internen und externen Clients.

  • Sie benötigen zusätzliche Zertifikate, um die Verschlüsselung von SMTP-Verbindungen zwischen Exchange-Servern und externen Messagingservern zu erzwingen.

Die folgenden Elemente der Planung und Bereitstellung für Exchange 2016 sind wichtige Faktoren für Ihre Zertifikatanforderungen:

Zurück zum Seitenanfang

Die Exchange-Dienste, denen Zertifikate zugewiesen werden können, werden in der folgenden Tabelle beschrieben.

 

Dienst Beschreibung

IIS (HTTP)

Standardmäßig werden die folgenden Dienste unter der Standardwebsite in den Clientzugriffs- (Front-End-)Diensten auf einem Postfachserver angeboten und von Clients zum Herstellen einer Verbindung mit Exchange verwendet:

  • AutoErmittlung

  • Exchange ActiveSync

  • Exchange-Verwaltungskonsole

  • Exchange-Webdienste

  • Offlineadressbuch-Verteilung

  • Outlook Anywhere (RPC über HTTP)

  • Outlook MAPI über HTTP

  • Outlook im Web

  • Remote-PowerShell*

Da Sie einer Website nur ein einzelnes Zertifikat zuordnen können, müssen alle DNS-Namen, mit denen Clients eine Verbindung zu diesen Diensten herstellen, in das Zertifikat aufgenommen werden. Sie erreichen dies mit einem SAN-Zertifikat oder einem Platzhalterzertifikat.

POP oder IMAP

Die für POP oder IMAP verwendeten Zertifikate können sich von dem Zertifikat unterscheiden, das für IIS verwendet wird. Um jedoch die Verwaltung zu vereinfachen, wird empfohlen, auch die für POP oder IMAP verwendeten Hostnamen in Ihr IIS-Zertifikat aufzunehmen und dasselbe Zertifikat für alle diese Dienste zu verwenden.

SMTP

SMTP-Verbindungen von Clients oder Messagingservern werden von einem oder mehreren Empfangsconnectors akzeptiert, die im Front-End-Transportdienst auf dem Exchange-Server konfiguriert sind. Weitere Informationen finden Sie unter Empfangsconnectors.

Um TLS-Verschlüsselung für SMTP-Verbindungen festzulegen, können Sie ein separates Zertifikat für jeden Empfangsconnector verwenden. Das Zertifikat muss den DNS-Namen enthalten, der von den SMTP-Clients oder -Servern zum Herstellen der Verbindung mit dem Empfangsconnector verwendet wird. Zur einfacheren Zertifikatverwaltung können Sie alle DNS-Namen, für die TLS-Datenverkehr unterstützt werden muss, in einem einzelnen Zertifikat zusammenfassen.

Informationen zum Festlegen der gegenseitigen TLS-Authentifizierung, bei der die SMTP-Verbindungen zwischen den Quell- und Zielservern verschlüsselt und authentifiziert werden, finden Sie unter Grundlegendes zur Domänensicherheit.

Unified Messaging (UM)

Weitere Informationen finden Sie unter Bereitstellen von Zertifikaten für Unified Messaging.

Hybridbereitstellung mit Microsoft Office 365

Weitere Informationen finden Sie unter Zertifikatanforderungen für Hybridbereitstellungen.

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Weitere Informationen finden Sie unter S/MIME für die Nachrichtensignierung und -verschlüsselung.

* 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 die Zertifikate nicht für die Verwendung mit der Remote-PowerShell konfigurieren, solange Sie direkt eine Verbindung mit einem Exchange-Server herstellen (und nicht mit einem Lastenausgleich-Namespace). Wenn Sie die Remote-PowerShell verwenden, um eine Verbindung mit einem Exchange-Server von einem nicht der Domäne angehörenden Computer oder über das Internet herzustellen, müssen Sie Ihre Zertifikate für die Verwendung mit der Remote-PowerShell konfigurieren.

Zurück zum Seitenanfang

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.

  • Verwenden Sie so wenige Zertifikate wie möglich   Wahrscheinlich bedeutet dies, dass SAN-Zertifikate oder Platzhalterzertifikate am besten geeignet sind. Im Hinblick auf Interoperabilität mit Exchange sind beide von der Funktion her gleichwertig. Die Entscheidung zwischen einem SAN-Zertifikat und einem Platzhalterzertifikat wird mehr durch die wichtigsten (realen oder wahrgenommenen) Funktionen und Einschränkungen der einzelnen Zertifikattypen bestimmt, die unter Übersicht über Zertifikate beschrieben sind.

    Befinden sich z. B. alle Ihre allgemeinen Namen auf derselben Ebene von contoso.com, spielt es keine Rolle, ob Sie ein SAN-Zertifikat oder ein Platzhalterzertifikat verwenden. Muss das Zertifikat jedoch für autodiscover.contoso.com, autodiscover.fabrikam.com und autodiscover.northamerica.contoso.com verwendet werden, müssen Sie ein SAN-Zertifikat verwenden.

  • Verwenden Sie für Verbindungen zwischen Clients und externen Servern Zertifikate von einer kommerziellen Zertifizierungsstelle   Obwohl die meisten Clients dafür konfiguriert werden können, beliebigen Zertifikaten oder Zertifikatausstellern zu vertrauen, ist es wesentlich einfacher, ein Zertifikat von einer kommerziellen Zertifizierungsstelle für Clientverbindungen mit Ihren Exchange-Servern zu verwenden. Auf dem Client ist keine Konfiguration erforderlich, um einem Zertifikat zu vertrauen, das von einer kommerziellen Zertifizierungsstelle ausgestellt ist. Viele kommerzielle Zertifizierungsstellen bieten Zertifikate, die speziell für Exchange konfiguriert sind. Sie können das EAC oder die Exchange-Verwaltungsshell zum Generieren von Zertifikatanforderungen verwenden, die bei den meisten kommerziellen Zertifizierungsstellen funktionieren.

  • Wählen Sie die richtige kommerzielle Zertifizierungsstelle   Vergleichen Sie die Preise und Funktionen von Zertifikaten zwischen Zertifizierungsstellen. Beispiel:

    • Wählen Sie eine Zertifizierungsstelle, die „Unified Communications-Zertifikate“ (UC) zur Verwendung mit Exchange unterstützt. Weitere Informationen finden Sie unter Unified Communications-Zertifikat-Partner.

    • Überprüfen Sie, ob die Clients (Betriebssysteme, Browser und mobile Geräte), die eine Verbindung mit Ihren Exchange-Servern herstellen, die Zertifizierungsstelle als vertrauenswürdig einstufen.

    • Überprüfen Sie, ob die Zertifizierungsstelle die Art von Zertifikat unterstützt, die Sie benötigen. Nicht alle Zertifizierungsstellen unterstützen z B. SAN-Zertifikate, möglicherweise beschränkt die Zertifizierungsstelle die Anzahl von allgemeinen Namen in einem SAN-Zertifikat, oder sie berechnet zusätzliche Kosten basierend auf der Anzahl der allgemeinen Namen in einem SAN-Zertifikat.

    • Erkundigen Sie sich, ob die Zertifizierungsstelle eine Karenzzeit bietet, in der Sie zusätzliche allgemeine Namen zu SAN-Zertifikaten hinzufügen können, nachdem sie kostenlos ausgestellt wurden.

    • Überprüfen Sie, ob die Lizenz des Zertifikats die Verwendung des Zertifikats auf der erforderlichen Anzahl von Servern zulässt. Bei einigen Zertifizierungsstellen darf ein Zertifikat nur auf einem Server verwendet werden.

  • Verwenden Sie den Exchange Zertifikat-Assistenten   Ein häufiger Fehler beim Erstellen von Zertifikaten ist es, mindestens einen allgemeinen Namen zu vergessen, der für die Dienste erforderlich ist, die Sie verwenden möchten. Der Zertifikat-Assistent in der Exchange-Verwaltungskonsole unterstützt Sie dabei, die richtige Liste allgemeiner Namen in die Zertifikatanforderung aufzunehmen. Im Assistenten können Sie die Dienste angeben, die das Zertifikat verwenden werden. Der Assistent nimmt dann die allgemeinen Namen auf, die das Zertifikat für diese Dienste enthalten muss. Führen Sie den Zertifikat-Assistenten aus, wenn Sie die ersten Exchange 2016-Server bereitgestellt und festgelegt haben, welche Hostnamen für die verschiedenen Dienste in Ihrer Bereitstellung verwendet werden sollen.

  • Verwenden Sie so wenige Hostnamen wie möglich   Das Minimieren der Anzahl von Hostnamen in SAN-Zertifikaten verringert die Komplexität der Zertifikatverwaltung. Fühlen Sie sich nicht verpflichtet, die Hostnamen einzelner Exchange-Server in SAN-Zertifikaten aufzunehmen, wenn die beabsichtigte Verwendung des Zertifikats dies nicht erfordert. In der Regel müssen Sie nur die DNS-Namen aufnehmen, die internen Clients, externen Clients oder externen Servern angezeigt werden, die das Zertifikat zum Herstellen einer Verbindung mit Exchange verwenden.

    Für eine einfache Exchange 2016-Organisation namens Contoso ist dies ein hypothetisches Beispiel für die mindestens erforderlichen Hostnamen:

    • mail.contoso.com   Dieser Hostname deckt die meisten Verbindungen mit Exchange ab, einschließlich Outlook, Outlook im Web, OAB-Verteilung, Exchange-Webdienste, POP3, IMAP4, SMTP, Exchange-Verwaltungskonsole und Exchange ActiveSync.

    • autodiscover.contoso.com   Dieser spezifische Hostname wird von Clients benötigt, die die AutoErmittlung unterstützen, einschließlich Outlook-, Exchange ActiveSync- und Exchange-Webdienste-Clients. Weitere Informationen finden Sie unter AutoErmittlungsdienst.

    • legacy.contoso.com   Dieser Hostname ist in einem Koexistenzszenario mit Exchange 2010 erforderlich. Wenn Sie über Clients mit Postfächern auf Exchange 2010-Servern verfügen, wird durch die Konfiguration eines entsprechenden Hostnamens verhindert, dass die Benutzer beim Upgrade eine zweite URL benötigen.

Zurück zum Seitenanfang

Einige interessante Eigenschaften der standardmäßigen selbstsignierten Zertifikate, die in der Exchange-Verwaltungskonsole und/oder der Exchange-Verwaltungsshell auf einem Exchange-Server angezeigt werden, werden in der folgenden Tabelle beschrieben.

 

Name (FriendlyName*)

Microsoft Exchange

Microsoft Exchange-Zertifikat für die Serverauthentifizierung

WMSVC

Subject

CN=<ServerName>   Beispiel: CN=Mailbox01.

CN=Microsoft Exchange Server Auth Certificate

CN=WMSvc-<ServerName>   Beispiel: CN=WMSvc-Mailbox01.

Alternative Antragstellernamen (CertificateDomains)

<ServerName>   Beispiel: Mailbox01.

<ServerFQDN>   Beispiel: Mailbox01.contoso.com.

n/v

WMSvc-<ServerName>   Beispiel: WMSvc-Mailbox01.

Hat privaten Schlüssel (HasPrivateKey)

Ja (True)

Ja (True)

Ja (True)

PrivateKeyExportable*

False

Wahr

True

EnhancedKeyUsageList *

Serverauthentifizierung (1.3.6.1.5.5.7.3.1)

Serverauthentifizierung (1.3.6.1.5.5.7.3.1)

Serverauthentifizierung (1.3.6.1.5.5.7.3.1)

IISServices *

IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2   Beispiel: IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2.

n/v

n/v

IsSelfSigned

True

Wahr

Wahr

Aussteller

CN=<ServerName>   Beispiel: CN=Mailbox01.

CN=Microsoft Exchange Server Auth Certificate

CN=WMSvc-<ServerName>   Beispiel: CN=WMSvc-Mailbox01.

NotBefore

Datum/Uhrzeit der Installation von Exchange.

Datum/Uhrzeit der Installation von Exchange.

Datum/Uhrzeit der Installation des IIS-Webverwaltungsdiensts.

Gültig bis (NotAfter)

5 Jahre nach NotBefore.

5 Jahre nach NotBefore.

10 Jahre nach NotBefore.

Größe des öffentlichen Schlüssels (PublicKeySize)

2048

2048

2048

RootCAType

Registrierung

Keine

Registrierung

Dienste

IMAP, POP, IIS, SMTP

SMTP

Keine

* Diese Eigenschaften sind in der Standardansicht der Exchange-Verwaltungsshell nicht sichtbar. Um sie anzuzeigen, müssen Sie mit den Cmdlets Format-Table oder Format-List den Eigenschaftennamen (genauen Namen oder Platzhalterübereinstimmung) angeben. Beispiel:

  • Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *

  • Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*

Weitere Informationen finden Sie unter Get-ExchangeCertificate.

Weitere Informationen zu den standardmäßigen selbstsignierten Zertifikaten, die im Windows Zertifikat-Manager sichtbar sind, werden in der folgenden Tabelle beschrieben.

 

Anzeigename

Microsoft Exchange

Microsoft Exchange-Zertifikat für die Serverauthentifizierung

WMSVC

Signaturalgorithmus

sha1RSA

sha1RSA

sha1RSA

Signaturhashalgorithmus

sha1

sha1

sha1

Schlüsselverwendung

Digitale Signatur, Schlüsselverschlüsselung (a0)

Digitale Signatur, Schlüsselverschlüsselung (a0)

Digitale Signatur, Schlüsselverschlüsselung (a0), Datenverschlüsselung (b0 00 00 00)

Basiseinschränkungen

Subject Type=End Entity.

Path Length Constraint=None.

Subject Type=End Entity.

Path Length Constraint=None.

N/V

Fingerabdruckalgorithmus

sha1

sha1

sha1

Normalerweise verwenden Sie nicht den Windows Zertifikat-Manager zum Verwalten von Exchange-Zertifikaten (verwenden Sie die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell). Beachten Sie, dass das WMSVC-Zertifikat kein Exchange-Zertifikat ist.

Zurück zum Seitenanfang

 
Anzeigen: