Digitale Zertifikate und Verschlüsselung in Exchange Server
Verschlüsselung und digitale Zertifikate sind wichtige Faktoren in jeder Organisation. Standardmäßig ist Exchange Server so konfiguriert, dass transport Layer Security (TLS) verwendet wird, um die Kommunikation zwischen internen Exchange-Servern und zwischen Exchange-Diensten auf dem lokalen Server zu verschlüsseln. 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.
Hinweis
Exchange Server 2019 enthält wichtige Änderungen, um die Sicherheit von Client- und Serververbindungen zu verbessern. Die Standardkonfiguration für die Verschlüsselung aktiviert nur TLS 1.2 und deaktiviert die Unterstützung älterer Algorithmen (d. h. DES, 3DES, RC2, RC4 und MD5). Außerdem werden Schlüsselaustauschalgorithmen mit elliptischen Kurven Algorithmen ohne elliptische Kurven vorgezogen. In Exchange Server 2016 und höher werden alle Kryptografieeinstellungen von der im Betriebssystem angegebenen Konfiguration geerbt. Weitere Informationen finden Sie unter TLS-Leitfaden für Exchange Server.
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 Server erforderlich sind, finden Sie unter Zertifikatprozeduren in Exchange Server.
Ü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 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 tragen dazu bei, die ausgetauschten Daten vor Diebstahl oder Manipulation zu schützen.
Authentifizierung: Sie überprüfen, ob ihre Inhaber (Personen, Websites und sogar Netzwerkgeräte wie Router) wirklich wer oder was sie zu sein behaupten. 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. Es ist schwierig, eine Infrastruktur für die Zertifikatlebenszyklusverwaltung einzurichten. 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 vorausplanen, 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 wird, für die Website https://www.contoso.comverwendet 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 www.contoso.com-Zertifikat nicht für ftp.contoso.com verwenden, auch 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:
|
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:
|
Flexibilität. Sie müssen keine Liste von Hosts angeben, wenn Sie das Zertifikat anfordern, und Sie können das Zertifikat auf einer beliebigen Anzahl von Hosts verwenden, die Sie in Zukunft möglicherweise 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. Oder Sie können das *.eu.contoso.com-Zertifikat 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. |
Zertifikate in Exchange
Wenn Sie Exchange 2016 oder Exchange 2019 auf einem Server installieren, werden von Exchange zwei selbstsignierte Zertifikate erstellt und installiert. Ein drittes selbstsigniertes Zertifikat wird von Microsoft Windows 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:
|
| 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 Exchange Server 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. Anweisungen 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 Zertifikate 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 Server sind wichtige Treiber für Ihre Zertifikatanforderungen:
Lastenausgleich: Planen Sie, den verschlüsselten Kanal auf dem Lastenausgleichs- oder Reverseproxyserver zu beenden, Lastenausgleichsmodule der Schicht 4 oder Schicht 7 zu verwenden und Sitzungsaffinität oder keine Sitzungsaffinität zu verwenden? Weitere Informationen finden Sie unter Lastenausgleich in Exchange 2016.
Namespaceplanung: Welche Versionen von Exchange sind vorhanden, verwenden Sie das gebundene oder ungebundene Namespacemodell und verwenden Split-Brain-DNS (konfigurieren unterschiedliche IP-Adressen für denselben Host basierend auf internem und externem Zugriff)? Weitere Informationen finden Sie unter Namespaceplanung in Exchange 2016.
Clientkonnektivität: Welche Dienste verwenden Ihre Clients (webbasierte Dienste, POP, IMAP usw.), und welche Versionen von Exchange sind beteiligt? Weitere Informationen finden Sie in den folgenden Themen:
Zertifikatanforderungen für Exchange-Dienste
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:
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 zur gegenseitigen TLS-Authentifizierung, bei der die SMTP-Verbindungen zwischen dem Quell- und dem Zielserver verschlüsselt und authentifiziert sind, finden Sie unter Domänensicherheit. |
| Unified Messaging (UM) | Weitere Informationen finden Sie unter Deploying Certificates for UM. Hinweis: UM ist in Exchange 2019 nicht verfügbar. |
| Hybridbereitstellung mit Microsoft 365 oder Office 365 | Weitere Informationen finden Sie unter Certificate Requirements for Hybrid Deployments. |
| 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 remote PowerShell verwenden möchten, um von einem Computer, der kein Mitglied der Domäne ist, eine Verbindung mit einem Exchange-Server herzustellen, oder um eine Verbindung über das Internet herzustellen, müssen Sie Ihre Zertifikate für die Verwendung mit Remote-PowerShell konfigurieren.
Bewährte Methoden für Exchange-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.
Verwenden Sie so wenige Zertifikate wie möglich: Sehr wahrscheinlich bedeutet dies die Verwendung von SAN-Zertifikaten oder Wildcard-Zertifikaten. 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 digitale Zertifikate beschrieben sind.
Wenn sich beispielsweise alle Gängigen Namen auf derselben Ebene contoso.com befinden, spielt es keine Rolle, ob Sie ein SAN-Zertifikat oder ein Wildcardzertifikat 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 von Zertifikaten von einer kommerziellen Zertifizierungsstelle für Client- und externe Serververbindungen: Obwohl Sie die meisten Clients so konfigurieren können, dass sie jedem Zertifikat oder Zertifikataussteller vertrauen, ist es viel 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 aus: Vergleichen Sie Zertifikatpreise und -features zwischen Zertifizierungsstellen. Beispiel:
Ü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. Beispielsweise unterstützen nicht alle Zertifizierungsstellen SAN-Zertifikate, die Zertifizierungsstelle kann die Anzahl der allgemeinen Namen begrenzen, die Sie in einem SAN-Zertifikat verwenden können, oder die Zertifizierungsstelle kann zusätzliche Gebühren basierend auf der Anzahl gängiger Namen in einem SAN-Zertifikat berechnen.
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 des Exchange-Zertifikat-Assistenten: Ein häufiger Fehler beim Erstellen von Zertifikaten besteht darin, einen oder mehrere allgemeine Namen zu vergessen, die für die Dienste erforderlich sind, die Sie verwenden möchten. Der Zertifikat-Assistent im Exchange Admin Center hilft Ihnen, die richtige Liste allgemeiner Namen in die Zertifikatanforderung aufzunehmen. Mit dem Assistenten können Sie die Dienste angeben, die das Zertifikat verwenden, und die allgemeinen Namen enthalten, die Sie im Zertifikat für diese Dienste benötigen. Führen Sie den Zertifikat-Assistenten aus, wenn Sie Ihre anfängliche Gruppe von Exchange 2016- oder Exchange 2019-Servern bereitgestellt und ermittelt haben, welche Hostnamen für die verschiedenen Dienste für Ihre Bereitstellung verwendet werden sollen.
Verwenden Sie so wenige Hostnamen wie möglich: Die Minimierung der Anzahl von Hostnamen in SAN-Zertifikaten reduziert die Komplexität, die mit der Zertifikatverwaltung verbunden ist. 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 Server Organisation namens Contoso ist dies ein hypothetisches Beispiel für die mindest erforderlichen Hostnamen:
mail.contoso.com: Dieser Hostname deckt die meisten Verbindungen mit Exchange ab, einschließlich Outlook, Outlook im Web, OAB-Verteilung, Exchange-Webdienste, Exchange Admin Center und Exchange ActiveSync.
autodiscover.contoso.com: Dieser spezifische Hostname ist für Clients erforderlich, die die AutoErmittlung unterstützen, einschließlich Outlook-, Exchange ActiveSync- und Exchange-Webdienstclients. Weitere Informationen finden Sie unter AutoErmittlungsdienst.
Eigenschaften der standardmäßigen selbstsignierten Zertifikate
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.
| Eigenschaft | Microsoft Exchange | Microsoft Exchange-Zertifikat für die Serverauthentifizierung | WMSVC |
|---|---|---|---|
| Betreff | CN=<ServerName> (Beispiel: CN=Mailbox01) |
CN=Microsoft Exchange Server Auth Certificate |
CN=WMSvc-<ServerName> (Beispiel: CN=WMSvc-Mailbox01) |
| Alternative Antragstellernamen (CertificateDomains) | <ServerName> (z. B. Mailbox01) <ServerFQDN> (z. B. Mailbox01.contoso.com) |
keine | WMSvc-<ServerName> (Beispiel: WMSvc-Mailbox01) |
| Verfügt über einen privaten Schlüssel (HasPrivateKey) | Ja (True) | Ja (True) | Ja (True) |
| PrivateKeyExportable* | Falsch | 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) |
keine | Keine |
| IsSelfSigned | True | True | 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. |
| Läuft ab (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.
| Eigenschaft | Microsoft Exchange | Microsoft Exchange-Zertifikat für die Serverauthentifizierung | WMSVC |
|---|---|---|---|
| Signaturalgorithmus | sha256RSA1 | sha256RSA1 | sha256RSA1 |
| Signaturhashalgorithmus | sha2561 | sha2561 | sha2561 |
| 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 |
Subject Type=End Entity |
n/v |
| Fingerabdruckalgorithmus | sha2561 | sha2561 | sha2561 |
1 Gilt für Neuinstallationen von Exchange 2016 Cumulative Update 22 oder höher und Exchange 2019 Cumulative Update 11 oder höher. Weitere Informationen finden Sie unter Exchange Server 2019- und 2016-Zertifikate, die während des Setups erstellt wurden, sha-1-Hash verwenden.
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.