Problembehandlung der Fehler 1037 und 2019 für das Zertifikat für die direkte Vertrauensstellung

 

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

Letztes Änderungsdatum des Themas: 2007-09-13

In diesem Thema wird erläutert, wie die Problembehandlung der Ereignisse 1037 und 2019 durchgeführt wird. Diese Ereignisse stehen im Zusammenhang mit Zertifikaten für die direkte Vertrauensstellung.

Die Ereignisse 1037 und 2019 sind Warnereignisse, die anzeigen, dass ein Problem aufgetreten ist, als Microsoft Exchange versucht hat, ein internes Transportzertifikat (auch als Zertifikat für die direkte Vertrauensstellung bezeichnet) auf dem Computer zu überprüfen, auf dem die Ereignisse aufgetreten sind. In Microsoft Exchange Server 2007 bedeutet "direkte Vertrauensstellung", dass das Vorhandensein des Zertifikats im Active Directory-Verzeichnisdienst oder im ADAM-Verzeichnisdienst (Active Directory Application Mode) das Zertifikat bestätigt. Active Directory wird als ein vertrauenswürdiger Speichermechanismus betrachtet. Wenn die direkte Vertrauensstellung verwendet wird, ist es nicht von Bedeutung, ob das Zertifikat selbstsigniert oder von einer Zertifizierungsstelle signiert ist.

Microsoft Exchange verwendet standardmäßig anstelle eines benutzerdefinierten Zertifikats eines Drittanbieters ein selbstsigniertes Zertifikat, das von Microsoft Exchange installiert wird. Sie können jedoch auch ein benutzerdefiniertes Zertifikat für die direkte Vertrauensstellung auswählen.

Das Problem, das durch die Ereignisse 1037 und 2019 angezeigt wird, wird durch mindestens eine der folgenden Bedingungen verursacht:

  • Der SMTP-Dienst (Simple Mail Transfer Protocol) ist nicht für das Zertifikat aktiviert. Standardmäßig ist für selbstsignierte interne Transportzertifikate der SMTP-Dienst aktiviert. Wird allerdings ein benutzerdefiniertes Zertifikat installiert und für die direkte Vertrauensstellung verwendet, ist der SMTP-Dienst ggf. nicht aktiviert.

  • Das Netzwerkdienstkonto besitzt möglicherweise nicht die richtigen Berechtigungen für die Schlüssel im folgenden Verzeichnis: C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Microsoft\Crypto\RSA\MachineKeys, wobei C:\ das Verzeichnis ist, in das Exchange 2007 installiert wurde.

  • Die Hostnamenabfrage im Zertifikatauswahlprozess führt möglicherweise aufgrund einer falschen DNS- oder Computernamenkonfiguration zu einem Fehler.

  • Die Serverfunktion Hub-Transport ist für die Verwendung von Netzwerklastenausgleich konfiguriert. Die Serverfunktion Hub-Transport wird nicht in einer Cluster- oder Netzwerklastenausgleich-Konfiguration für den Zweck der Exchange Server-Authentifizierung für Szenarien wie z. B. die Kommunikation zwischen Hub-Transport-Servern unterstützt. Die Verwendung von Netzwerklastenausgleich kann zu einem Fehler bei der Hostnamenabfrage während der Zertifikatüberprüfung führen.

Bevor Sie beginnen

Damit Sie das nachstehende Verfahren ausführen können, muss Folgendes an das verwendete Konto delegiert worden sein:

  • Exchange-Administrator mit Leserechten (Rolle), um das Cmdlet Get-ExchangeCertificate ausführen zu können.

  • Exchange-Serveradministrator-Rolle und lokale Gruppe Administratoren für den Zielserver, um das Cmdlet New-ExchangeCertificate oder Enable-ExchangeCertificate ausführen zu können.

  • Lokale Gruppe Administratoren für den Zielserver, um Filemon (Filemon.exe) ausführen zu können.

Um eines dieser Cmdlets oder Filemon 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.

Weitere Informationen über Berechtigungen, das Delegieren von Funktionen und die zum Verwalten von Exchange 2007 erforderlichen Rechte finden Sie unter Überlegungen zu Berechtigungen.

Verfahren

Um die Warnereignisse zu beheben, führen Sie mindestens eine der folgenden Aktionen durch:

  • Stellen Sie sicher, dass der SMTP-Dienst für das Zertifikat aktiviert ist.

    Führen Sie das folgende Cmdlet in der Exchange-Verwaltungsshell aus.

    Get-ExchangeCertificate | fl *

    Hinweis

    Wenn Sie Exchange Server 2007 Service Pack 1 oder höher ausführen, verwenden Sie nicht das Sternchen (*) im Befehlsargument.

    Die Ausgabe zeigt Details zu allen Zertifikaten, die auf dem Computer installiert sind.

    • Wenn das Attribut IsSelfSign den Wert True besitzt, handelt es sich bei dem Zertifikat um das selbstsignierte Zertifikat, das von Microsoft Exchange installiert wird. Sie können mehrere selbstsignierte Zertifikate auf dem Server installieren. Es wird jedoch nur das gültige Zertifikat mit dem aktuellsten Zeitstempel verwendet.

    • Wenn das Attribut IsSelfSign den Wert False besitzt, handelt es sich bei dem Zertifikat um das Zertifikat eines Drittanbieters oder um ein benutzerdefiniertes Zertifikat.

    Wenn das Attribut Services nicht den Wert SMTP enthält, führen Sie das folgende Cmdlet in der Exchange-Verwaltungsshell aus.

    Enable-ExchangeCertificate -Thumbprint <insert_certificate_thumbprint> -Services:SMTP
    

    Hinweis

    Dieser Befehl hängt SMTP an alle Dienste an, die bereits für das Zertifikat aktiviert sind. Er entfernt keine vorhandenen Dienste.

  • Ermitteln Sie, ob das Netzwerkdienstkonto über die richtigen Berechtigungen verfügt. Stellen Sie sicher, dass das Netzwerkdienstkonto Leseberechtigungen für alle Schlüssel im folgenden Verzeichnis besitzt: C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Microsoft\Crypto\RSA\MachineKeys, wobei C:\ das Verzeichnis ist, in das Exchange 2007 installiert wurde.

    Hinweis

    Filemon kann auch verwendet werden, wenn Sie ermitteln möchten, ob es sich um ein Berechtigungsproblem handelt.

  • Starten Sie Filemon, und zeichnen Sie das Auftreten dieses Fehlers auf. Überprüfen Sie die sich ergebende Protokolldatei auf Ereignisse des Typs Zugriff verweigert. Vergewissern Sie sich, dass die in der lokalen DNS-Konfiguration konfigurierten Parameter den Kriterien entsprechen, die im Überprüfungsprozess für die Zertifikate für die direkte Vertrauensstellung verwendet werden. Die lokale DNS-Konfiguration sollte mit dem selbstsignierten Zertifikat verglichen werden, das von Microsoft Exchange installiert wird, weil dieses Zertifikat für die direkte Vertrauensstellung erforderlich ist. Der Überprüfungsprozess für die internen Transportzertifikate überprüft die folgenden DNS-Konfigurationseinstellungen:

    • DnsFullyQualifiedDomainName

    • DnsHostName

    • DnsPhysicalFullyQualifiedDomainName

    • DnsPhysicalHostName

    Sie können die Kriterien für das Zertifikat mithilfe der Ablaufverfolgung des Exchange-Problembehandlungs-Assistenten überprüfen. Verwenden Sie zu diesem Zweck die folgenden Komponenten und Tags:

    • Common\Certificate

    • NetworkingLayer\Certificate

    • Transport\Certificate

    Die Ablaufverfolgung des Exchange-Problembehandlungs-Assistenten generiert Ausgaben, mit denen Sie ermitteln können, ob der FQDN (Fully Qualified Domain Name, vollqualifizierter Domänenname) den Domänen entspricht, die für das selbstsignierte Zertifikat konfiguriert wurden. Wenn der FQDN nicht übereinstimmt, ist er wahrscheinlich falsch konfiguriert. In diesem Fall sollten Sie ermitteln, von welchem Speicherort das Zertifikat die Daten abruft.

  • Wenn der Servercomputer mit Exchange in einer Umgebung mit Netzwerklastenausgleich ausgeführt wird, wird ggf. während des Überprüfungsprozesses für die Zertifikate für die direkte Vertrauensstellung ein unerwarteter FQDN hinzugefügt. Wenn Sie eine unerwartete Domäne bemerken, überprüfen Sie die Netzwerklastenausgleich-Konfiguration daraufhin, ob die unerwartete Domäne dort konfiguriert ist. Wenn die Netzwerklastenausgleich-Konfiguration den unerwarteten FQDN enthält, ändern Sie die Netzwerklastenausgleich-Konfiguration so, dass sie nicht bewirkt, dass ein Fehler der Zertifikatüberprüfung auftritt.

Weitere Informationen

Weitere Informationen hierzu finden Sie unter den folgenden Themen: