Erstellen eines Zertifikats oder einer Zertifikatsanforderung für TLS

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2011-11-04

In diesem Thema wird das Erstellen eines X.509 Transport Layer Security-Zertifikats (TLS) oder einer Zertifikatsanforderung mithilfe der ExchangeCertificate-Cmdlets in der Exchange-Verwaltungsshell erläutert.

Wichtig

Bevor Sie dieses Thema lesen, sollten Sie sich unbedingt mit der allgemeinen Zertifikatverwendung in Microsoft Exchange Server 2007 vertraut machen. Siehe Verwendung von Zertifikaten in Exchange 2007 Server.

In Hinsicht auf die Verschlüsselung handelt es sich bei dem Zertifikat und zugehörigen privaten Schlüsseln, die vom Cmdlet New-ExchangeCertificate generiert werden, um TLS-Schlüssel. Mit dem Cmdlet New-ExchangeCertificate können Sie Metadaten zum Zertifikat angeben, sodass verschiedene Dienste dasselbe Zertifikat und denselben privaten Schlüssel verwenden können. Bevor Sie Zertifikate oder Zertifikatsanforderungen für Exchange-Dienste erstellen, die TLS verwenden, sollten Ihnen die Metadaten bekannt sein, die von den Zertifikaten für SSL- und TLS-Dienste verwendet werden. Diese Metadaten werden als "Felder" im generierten Zertifikat bezeichnet.

Zum Anzeigen der Felder von Computerzertifikaten auf einem bestimmten Computer können Sie das Cmdlet Get-ExchangeCertificate in der Exchange-Verwaltungsshell verwenden. Sie können auch das Zertifikat-Manager-Snap-In in Microsoft Management Console (MMC) verwenden. Weitere Informationen zum Verwenden des Zertifikat-Manager-Snap-Ins finden Sie unter Hinzufügen der Zertifikatverwaltung zur MMC (Microsoft Management Console).

Erläuterungen zu den Feldern, die von Zertifikaten für TLS-Dienste verwendet werden

Wenn Sie das Cmdlet New-ExchangeCertificate zum Generieren einer Zertifikatsanforderung für eine Zertifizierungsstelle eines Drittanbieters oder einer anderen Public-Key-Infrastruktur verwenden, müssen Sie prüfen, welche Zertifikatsfelder und welches Zertifikatsformat für die Zertifizierungsstelle erforderlich sind.

In diesem Abschnitt werden die wichtigsten Zertifikatsfelder erläutert, und es werden einige bewährte Methoden zum Generieren von Zertifikaten und Zertifikatsanforderungen genannt.

Subjektname

Der Subjektname eines TLS-Zertifikats ist das Feld, das von DNS-gestützten Diensten verwendet wird. Mit dem Feld für den Subjektnamen wird ein Zertifikat an einen bestimmten Server- oder Domänennamen gebunden.

Ein Subjektname ist ein X.500 DN (Distinguished Name), der sich aus ein oder mehreren RDNs (Relative Distinguished Name) zusammensetzt. In der folgenden Tabelle sind häufig verwendete RDNs zur Angabe von Organisationen oder Serverentitäten aufgeführt.

Name Abkürzung Typ Max. Größe Häufigkeit max./empfohlen in Zertifikat/Anforderung Reihenfolge in Subjekt

Country/Region (Land/Region)

C

ASCII

2

1\1

1

Domain Component (Domänenkomponente)

DC

ASCII

255

Viele

1

State or Province (Bundesland oder Kanton)

S

Unicode

128

1

2

Locality (Ort)

L

Unicode

128

1

3

Organization (Organisation)

O

Unicode

64

1\1

4

Organizational Unit (Organisationseinheit)

OU

Unicode

64

Viele/Viele

5

Allgemeiner Name

CN

Unicode

64

Viele/1

6

Bei den Codes für Land/Region handelt es sich um die ISO 3166-1-Codes. Weitere Informationen finden Sie unter English country names and code elements.

Hinweis

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

Die Domänenkomponente und Land/Region schließen sich aufgrund der Konvention gegenseitig aus. Eine bewährte Methode besteht darin, auf den Namen entweder mit Land/Region oder mit einem DNS-Namen (Domain Name System) zu verweisen. Sie müssen außerdem darauf achten, dass es sich bei der maximalen Größe der Domänenkomponente (255 Zeichen) um die Summe aller Werte für die Domänenkomponente handelt.

Wichtig

Zwar können Zertifikate mehrere Felder für den allgemeinen Namen aufweisen, doch werden einige Dienste unter der Voraussetzung implementiert, dass nur ein allgemeiner Name vorhanden ist. Daher können mehrere allgemeine Namen zu Problemen bei der Interoperabilität führen. Es wird empfohlen, das Zertifikat oder die Zertifikatsanforderung mit nur einem allgemeinen Namen zu erstellen.

Implementieren von RDNs (Relative Distinguished Name)

Subjektnamen werden im Cmdlet New-ExchangeCertificate als ein einzelner Parameter angegeben, der sich aus einer Reihe durch Komma getrennter Werte zusammensetzt. Jeder Name wird durch die Abkürzung für den RDN angegeben. Im folgenden Beispiel ist der Subjektname als Land/Region = US, Organisation = Contoso Corp und Allgemeiner Name = mail1.contoso.com angegeben:

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

Weitere Beispiele für Subjektnamen, die denselben Server darstellen können, sind:

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

Wenn Sie über einen registrierten DNS-Namen verfügen, der zum Senden von SMTP-Mail verwendet wird, besteht eine bewährte Methode darin, die Konvention für die Domänenkomponente und den DNS-Namen als Zertifikatsnamen zu verwenden, z. B. "DC=contoso", "DC=com", "CN=mail1.contoso.com".

Wenn Sie eine Zertifikatsanforderung für einen Anbieter einer Zertifizierungsstelle generieren, müssen Ihnen die Anforderungen für das Feld "Subjektname" der Zertifizierungsstelle und Ihre besonderen PKI-Anforderungen bekannt sein. In einigen Fällen müssen Sie möglicherweise den Code für Land/Region ("C") verwenden. Wenn dies der Fall ist, müssen Sie den RDN bei einer X.500-Registrierungsstelle registrieren.

Internationale Subjektnamen

Im Falle von Subjektnamen, die Nicht-ASCII-Zeichen enthalten, können Sie den Parameter SubjectName als einen in Anführungszeichen eingeschlossenen DN (Distinguished Name) wie folgt eingeben:

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Subjektnamen und Domänennamen

Gemäß der Konvention kann ein allgemeiner Name einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) enthalten. Obwohl diese Methode weit verbreitet ist und empfohlen wird, sind die folgenden beiden Aspekte zu beachten.

Erstens: Die maximale Größe des Felds für den allgemeinen Namen beträgt 64 Zeichen. Dies sind weniger Zeichen als die maximale Größe eines FQDN. Daher müssen Sie bei einem FQDN mit mehr als 64 Zeichen den Domänennamen unter dem alternativen Subjektnamen angeben. Mit dem Parameter DomainName wird eine Zuordnung zum alternativen Subjektnamen im generierten Zertifikat erstellt.

Zweitens: Der FQDN ist auf eine Teilmenge des ASCII-Zeichensatzes beschränkt. Der allgemeine Name unterstützt jedoch Unicode. Daher können Sie ein gültiges Zertifikat mit einem CN erstellen, der wie ein DNS-Name erscheint, jedoch als DNS-Name ungültig ist. Eine Software, die nach einem FQDN in einem CN eines Zertifikats sucht, gibt nicht das richtige Ergebnis zurück, wenn der CN Nicht-ASCII-Zeichen enthält. Wenn Sie z. B. ein Zertifikat mit einem Subjektnamen mit "CN=mail.mïcrosoft.com" erstellen, wird der Name als FQDN ignoriert, da er ein Unicode-Zeichen enthält (das Zeichen "ï" mit diakritischem Zeichen (x00ef)). Mit bloßem Auge kann der Unicode-CN leicht für einen FQDN gehalten werden, da nur ein geringer Unterschied zwischen dem Zeichen "ï" mit diakritischem Zeichen (x00ef) und dem ASCII-Zeichen "i" (x0069) besteht. Für die Exchange-Zertifikatstask muss der CN des Subjekts kein gültiger FQDN sein. Dies bedeutet, dass mit dem Cmdlet standardmäßig der FQDN des Servers als Standard-CN eingefügt wird.

Domänennamen für Zertifikate

Im Falle von TLS müssen Zertifikate DNS-Namen enthalten, da TLS ein DNS-basiertes Protokoll ist. Clients prüfen den DNS-Namen des Servers, mit dem sie eine Verbindung herstellen, anhand des DNS-Namens, mit dem eine Verbindung erwartet wird. Dies gilt für Webbrowser, die eine Verbindung mit einer Website über HTTPS herstellen, und für SMTP-Server, die E-Mail über das Internet oder Intranet übertragen.

Ein einzelner Server kann mehrere DNS-Namen aus folgenden Gründen unterstützen:

  • Ein SMTP-Server unterstützt mehrere akzeptierte Domänen.

  • Ein Client kann auf einen E-Mail-Server mit dem Servernamen, dem Domänennamen, einem lokalen FQDN-Namen oder mit einem Namen für den Lastenausgleich zugreifen.

Wenn eine TLS-Verbindung hergestellt wurde und der Client den gesuchten Namen findet, werden die anderen Namen im Zertifikat vom Client ignoriert. Es können mehrere Domänen- und Servernamen zum Feld für den alternativen Subjektnamen eines TLS-Zertifikats hinzugefügt werden. Sie können ein Zertifikat erstellen, das mehrere alternative Subjektnamen enthält. Dazu verwenden Sie den Parameter DomainName im Cmdlet New-ExchangeCertificate. Der Parameter DomainName ist mehrwertig und kann daher mehrere Namen enthalten.

X.509-Zertifikate können keinen, einen oder mehrere DNS-Namen in der Zertifikatserweiterung für den alternativen Subjektnamen (SubjectAltName) enthalten. DNS-Namen in der Erweiterung SubjectAltName weisen dieselben Einschränkungen wie ein DNS-Name auf. Sie dürfen nicht mehr als 255 Zeichen umfassen und müssen sich aus den Zeichen A-Z, a-z, 0-9 und einem Gedankenstrich (-) zusammensetzen.

Namensvergleichslogik für die Funktion "Domänensicherheit"

Die Logik für den Zertifikatnamensvergleich für die Funktion Domänensicherheit überprüft beim Senden von Mail an eine Domäne, ob ein Domänenname im erhaltenen Zertifikat mit dem Domänennamen übereinstimmt. Der FQDN der Empfängerdomäne, woodgrovebank.com dient als Beispiel. Die Logik für den Zertifikatnamensvergleich durchsucht alle DNS-Namen in den Zertifikaten. Stimmt mindestens ein DNS-Name überein, wird das Zertifikat als Entsprechung für die angegebene Domäne verifiziert.

In diesem Beispiel akzeptiert die Logik für den Zertifikatnamensvergleich ein Zertifikat mit einer genauen Domänenübereinstimmung, z. B. woodgrovebank.com. Die Verwendung von Domänennamen mit Platzhalterzeichen in Zertifikaten wird ebenfalls unterstützt, sodass beispielsweise ein Zertifikat mit dem DNS-Namen *.woodgrovebank.com als Entsprechung akzeptiert wird. Weitere Informationen zu Domänennamen mit Platzhalterzeichen finden Sie unter "Domänennamen mit Platzhalterzeichen " weiter unten in diesem Thema.

Die Logik für den Zertifikatnamensvergleich durchsucht den DNS außerdem einen Knoten tief. Daher wird auch mail1.woodgrovebank.com auch als Entsprechung für woodgrovebank.com akzeptiert. DNS-Namen mit einer Tiefe von mehr als zwei Knoten werden jedoch nicht akzeptiert. "mail1.us.woodgrovebank.com" würde demnach z. B. nicht als Entsprechung für "woodgrovebank.com" akzeptiert.

Weitere Informationen dazu, wie Exchange Zertifikate auswählt, finden Sie unter SMTP-TLS-Zertifikatauswahl.

Bewährte Methoden für Domänennamen für Internet-SMTP

Wenn Sie ein Zertifikat oder eine Zertifikatsanforderung für einen Edge-Transport-Server mit SMTP-TLS über das Internet erstellen, sollte die folgende Gruppe von Domänennamen in der Anforderung enthalten sein:

  • Der vollqualifizierte Internetdomänenname des Servers   Dieser kann sich vom internen FQDN unterscheiden, der zwischen Edge-Transport-Servern und Hub-Transport-Servern verwendet wird, und sollte dem A-Datensatz entsprechen, der auf dem Internet-DNS-Server (öffentlichen DNS-Server) veröffentlicht ist. Dieser Name sollte als ein CN in den Parameter SubjectName im Cmdlet New-ExchangeCertificate eingegeben werden.

  • Alle Namen akzeptierter Domänen der Organisation   Verwenden Sie den Parameter IncludeAcceptedDomain des Cmdlets New-ExchangeCertificate, um den alternativen Subjektnamen für das generierte Zertifikat mit Daten aufzufüllen.

  • Der FQDN für den Connector, wenn dieser nicht durch eines der vorherigen Elemente abgedeckt ist   Verwenden Sie den Parameter DomainName im Cmdlet New-ExchangeCertificate, um den alternativen Subjektnamen für das generierte Zertifikat auszufüllen.

Bewährte Methoden für Domänennamen für einen Clientzugriffsserver

Wenn Sie ein Zertifikat oder eine Zertifikatsanforderung für einen Clientzugriffsserver erstellen, sollte die folgende Gruppe von Domänennamen in der Anforderung enthalten sein:

  • Lokaler oder NetBIOS-Name des Servers, z. B. owa1

  • Alle Namen akzeptierter Domänen für die Organisation, z. B. contoso.com

  • Der vollqualifizierte Domänenname (FQDN) für den Server, z. B. owa1.contoso.com

  • Der AutoErmittlungsdomänenname für die Domäne, z. B. Autodiscover.contoso.com

  • Die Identität für den Lastenausgleich des Servers (sofern verwendet), z. B. owa.contoso.com

Domänennamen mit Platzhalterzeichen

Bei Domänennamen mit Platzhalterzeichen handelt es sich um eine spezielle Art von Domänennamen, die mehrere Unterdomänen repräsentieren. Domänennamen mit Platzhalterzeichen können Zertifikate vereinfachen, da ein einziger Domänenname mit Platzhalterzeichen alle Unterdomänen für diese Domäne repräsentiert. Sie werden durch ein Sternchen (*) im DNS-Knoten dargestellt. So steht z. B. *.contoso.com für contoso.com und alle Unterdomänen von contoso.com. Wenn Sie ein Platzhalterzeichen verwenden, um ein Zertifikat oder eine Zertifikatsanforderung für alle akzeptierten Domänen zu erstellen, können Sie die Anforderung wesentlich vereinfachen.

Klonen eines vorhandenen Zertifikats

Exchange 2007 erstellt während der Installation ein selbstsigniertes Zertifikat, das alle Server- und Domänennamen verwendet, die Exchange zum Zeitpunkt der Installation bekannt sind. Diese Zertifikate sind 12 Monate gültig. In einigen Fällen kann es sinnvoll sein, diese Zertifikate zu klonen, wenn der Subjektname und der alternative Subjektname für andere Computer verwendet werden können. Beachten Sie, dass nur die Metadaten des Zertifikats und nicht die Schlüsselsätze geklont werden.

Um die folgenden Cmdlets auf einem Computer ausführen zu können, auf dem die Serverfunktion Edge-Transport installiert ist, müssen Sie sich mit einem Konto anmelden, das Mitglied der lokalen Gruppe Administratoren auf diesem Computer ist.

Um ein neues Zertifikat aus einem vorhandenen Zertifikat zu klonen, müssen Sie zunächst das aktuelle Zertifikat für die Domäne mit dem folgenden Befehl angeben:

Get-ExchangeCertificate -DomainName mail1.contoso.com

Dabei steht mail1.contoso.com für den Servernamen oder den FQDN, von dem Sie ein geklontes Zertifikat erstellen möchten.

Das erste Zertifikat, das in der Ausgabe aufgelistet ist, ist das SMTP-TLS-Standardzertifikat für den Server.

Führen Sie den folgenden Befehl aus, um das Zertifikat zu klonen:

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

Dabei stammt der Wert für Thumbprint aus dem ersten Zertifikat, das in der Ausgabe für Get-ExchangeCertificate aufgelistet war.

Mit diesem Befehl werden die Namen aus dem vorhandenen Zertifikat extrahiert, die durch den Fingerabdruck angegeben sind, und diese werden im neuen selbstsignierten Zertifikat verwendet.

Generieren von Anforderungen für Zertifikatsdienste von Drittanbietern

Wenn Sie eine Zertifizierungsstelle zum Generieren von Zertifikaten verwenden, müssen Sie eine Zertifikatsanforderung entsprechend den Anforderungen dieser Zertifizierungsstelle bereitstellen.

Zum Generieren einer Zertifikatsanforderung können Sie das Cmdlet New-ExchangeCertificate verwenden. Verwenden Sie zum Generieren einer Zertifikatsanforderung den Parameter GenerateRequest zusammen mit dem Parameter Path, um festzulegen, an welchem Speicherort die Anforderungsdatei erstellt werden soll. Bei der generierten Datei handelt es sich um eine PKCS #10-Anforderungsdatei (.req). PKCS #10 ist der Standard für die Syntax von Zertifikatsanforderungen, der durch RFC 2314 festgelegt ist (http://www.ietf.org/rfc/rfc2314.txt).

Hinweis

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

Die folgenden Beispiele zeigen einige typische Zertifikatsanforderungen.

Im ersten Beispiel wird eine Zertifikatsanforderung für den Server von Contoso "mail1" generiert. Der CN des Subjektnamens enthält den FQDN des Servers, und der alternative Subjektname enthält alle akzeptierten Domänen für Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

Im zweiten Beispiel wird eine Zertifikatsanforderung für den Server von Contoso "mail1" generiert. Contoso verfügt über einen Sendeconnector auf jedem Edge-Transport-Server, der den FQDN "mail.contoso.com" aufweist.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

Im dritten Beispiel wird eine Zertifikatsanforderung aus einem vorhandenen "Contoso.com"-Zertifikat erstellt.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

Im letzten Beispiel wird gezeigt, wie eine Zertifikatsanforderung mit einem Platzhalterzeichen für alle Unterdomänen von "Contoso.com" erstellt wird.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

Weitere Beispiele finden Sie im Microsoft Exchange Team Blog-Artikel Lessons Learned: Generating a Certificate with a 3rd Party CA.

Hinweis

UNRESOLVED_TOKEN_VAL(exBlog)

Installieren von Zertifikaten, die durch Zertifikatsanforderungen ausgegeben wurden

Nachdem Sie die Zertifikatsanforderung an eine Zertifizierungsstelle gesendet haben, gibt diese ein Zertifikat oder eine Kette von Zertifikaten aus. In beiden Fällen werden die Zertifikate in Form von Dateien zugestellt, die mit dem Cmdlet Import-ExchangeCertificate installiert werden müssen.

Wichtig

Verwenden Sie nicht das Zertifikat-Manager-Snap-In, um die Zertifikate für einen Dienst auf einem Exchange-Server zu importieren. Mit dem Zertifikat-Manager-Snap-In kann kein Import von Zertifikaten auf Exchange-Servern ausgeführt werden. Daher funktionieren TLS- oder andere Exchange-Zertifikatsdienste nicht.

Das folgende Beispiel zeigt, wie ein Zertifikat für SMTP-TLS importiert wird.

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

Im nächsten Beispiel wird gezeigt, wie ein Zertifikat importiert und für einen Clientzugriffsserver aktiviert wird, der POP3-Clients (Post Office Protocol Version 3) unterstützt.

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

Weitere Informationen

Weitere Informationen über Zertifizierungsstellen, die aktuell Exchange-spezifische Websites betreiben, finden Sie im Microsoft Knowledge Base-Artikel 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.

Weitere Informationen zu Kryptografie und Zertifikattechnologien und -konzepten finden Sie in den folgenden englischsprachigen Veröffentlichungen und unter folgendem Link: