Clients können sich nicht mit einem Server authentifizieren, nachdem Sie ein neues Zertifikat erhalten haben, um ein abgelaufenes Zertifikat auf dem Server zu ersetzen.

Dieser Artikel bietet eine Lösung für ein Problem, bei dem Clients sich nicht mit einem Server authentifizieren können, nachdem Sie ein neues Zertifikat erhalten haben, um ein abgelaufenes Zertifikat auf dem Server zu ersetzen.

Original Version des Produkts:   Windows 10 – alle Editionen, Windows Server 2012 R2
Ursprüngliche KB-Nummer:   822406

Problembeschreibung

Nachdem Sie ein abgelaufenes Zertifikat durch ein neues Zertifikat auf einem Server ersetzt haben, auf dem Microsoft Internet Authentication Service (IAS) oder Routing und RAS ausführt, können Clients mit erweiterbarer Authentifizierung Protocol-Transport Layer Security (EAP-TLS), die für die Überprüfung des Serverzertifikats konfiguriert sind, sich nicht mehr mit dem Server authentifizieren. Wenn Sie das System Protokoll in der Ereignisanzeige auf dem Clientcomputer anzeigen, wird das folgende Ereignis angezeigt.

Wenn Sie die ausführliche Protokollierung auf dem Server aktivieren, der IAS oder Routing und RAS ausführt (beispielsweisedurch Ausführen des netsh ras set tracing * enable Befehls), werden in der Datei Rastls. Log Informationen ähnlich der folgenden angezeigt, die generiert werden, wenn ein Client versucht, sich zu authentifizieren.

Hinweis

Wenn Sie IAS als RADIUS-Server für die Authentifizierung verwenden, sehen Sie sich dieses Verhalten auf dem IAS-Server an. Wenn Sie Routing und RAS verwenden und Routing und Remotezugriff für die Windows-Authentifizierung (nicht die RADIUS-Authentifizierung) konfiguriert sind, wird dieses Verhalten auf dem Routing-und RAS-Server angezeigt.

[1072] 15:47:57:280: CRYPT_E_NO_REVOCATION_CHECK wird nicht ignoriert

[1072] 15:47:57:280: CRYPT_E_REVOCATION_OFFLINE wird nicht ignoriert

[1072] 15:47:57:280: das Stammzertifikat wird nicht auf Widerruf überprüft.

[1072] 15:47:57:280: das Zertifikat wird auf Widerruf überprüft

[1072] 15:47:57:280:

[1072] 15:47:57:280: EapTlsMakeMessage (Example\client)

[1072] 15:47:57:280: >> empfangene Antwort (Code: 2)-Paket: ID: 11, length: 25, Typ: 0, TLS-BLOB-Länge: 0. Flags

[1072] 15:47:57:280: EapTlsSMakeMessage

[1072] 15:47:57:280: EapTlsReset

[1072] 15:47:57:280: Statusänderung in Initial

[1072] 15:47:57:280: GetCredentials

[1072] 15:47:57:280: der Name im Zertifikat lautet: Server.example.com

[1072] 15:47:57:312: BuildPacket

[1072] 15:47:57:312: << sendende Anforderung (Code: 1) Paket: ID: 12, length: 6, Type: 13, TLS BLOB length: 0. Flags: S

[1072] 15:47:57:312: Statusänderung in SentStart

[1072] 15:47:57:312:

[1072] 15:47:57:312: EapTlsEnd (Example\client)

[1072] 15:47:57:312:

[1072] 15:47:57:312: EapTlsEnd (Example\client)

[1072] 15:47:57:452:

[1072] 15:47:57:452: EapTlsMakeMessage (Example\client)

[1072] 15:47:57:452: >> empfangene Antwort (Code: 2) Paket: ID: 12, length: 80, Typ: 13, TLS-BLOB-Länge: 70. Flags: L

[1072] 15:47:57:452: EapTlsSMakeMessage

[1072] 15:47:57:452: MakeReplyMessage

[1072] 15:47:57:452: Erneutes Zuweisen des BLOB-Puffers für die Eingabe TLS

[1072] 15:47:57:452: SecurityContextFunction

[1072] 15:47:57:671: Statusänderung in SentHello

[1072] 15:47:57:671: BuildPacket

[1072] 15:47:57:671: << sendende Anforderung (Code: 1) Paket: ID: 13, length: 1498, Typ: 13, TLS-BLOB-Länge: 3874. Flags: LM

[1072] 15:47:57:702:

[1072] 15:47:57:702: EapTlsMakeMessage (Example\client)

[1072] 15:47:57:702: >> empfangene Antwort (Code: 2) Paket: ID: 13, length: 6, Type: 13, TLS BLOB length: 0. Flags

[1072] 15:47:57:702: EapTlsSMakeMessage

[1072] 15:47:57:702: BuildPacket

[1072] 15:47:57:702: << sendende Anforderung (Code: 1) Paket: ID: 14, length: 1498, Typ: 13, TLS-BLOB-Länge: 0. Flags: M

[1072] 15:47:57:718:

[1072] 15:47:57:718: EapTlsMakeMessage (Example\client)

[1072] 15:47:57:718: >> empfangene Antwort (Code: 2) Paket: ID: 14, length: 6, Type: 13, TLS BLOB length: 0. Flags

[1072] 15:47:57:718: EapTlsSMakeMessage

[1072] 15:47:57:718: BuildPacket

[1072] 15:47:57:718: << sendende Anforderung (Code: 1) Paket: ID: 15, length: 900, Typ: 13, TLS-BLOB-Länge: 0. Flags

[1072] 15:48:12:905:

[1072] 15:48:12:905: EapTlsMakeMessage (Example\client)

[1072] 15:48:12:905: >> empfangene Antwort (Code: 2) Paket: ID: 15, length: 6, Type: 13, TLS BLOB length: 0. Flags

[1072] 15:48:12:905: EapTlsSMakeMessage

[1072] 15:48:12:905: MakeReplyMessage

[1072] 15:48:12:905: SecurityContextFunction

[1072] 15:48:12:905: Statusänderung in SentFinished. Fehler: 0x80090318

[1072] 15:48:12:905: Aushandlung nicht erfolgreich

[1072] 15:48:12:905: BuildPacket

[1072] 15:48:12:905: << Sendefehler (Code: 4) Paket: ID: 15, length: 4, Typ: 0, TLS BLOB Le

Ursache

Dieses Problem kann auftreten, wenn alle folgenden Bedingungen erfüllt sind:

  • Der IAS oder Routing-und RAS-Server ist ein Domänenmitglied, aber die Funktion für automatische Zertifikatanforderungen (automatische Registrierung) ist in der Domäne nicht konfiguriert. Oder: IAS oder Routing und RAS-Server sind kein Domänenmitglied.
  • Sie fordern und erhalten manuell ein neues Zertifikat für den IAS oder den Routing-und RAS-Server.
  • Das abgelaufene Zertifikat wird nicht von IAS oder Routing und RAS-Server entfernt. Wenn ein abgelaufenes Zertifikat auf dem IAS oder Routing-und RAS-Server zusammen mit einem neuen gültigen Zertifikat vorhanden ist, ist die Clientauthentifizierung nicht erfolgreich. Das Ergebnis "Error 0x80090328", das im Ereignisprotokoll auf dem Clientcomputer angezeigt wird, entspricht "abgelaufenes Zertifikat".

Problemumgehung

Um dieses Problem zu umgehen, entfernen Sie das abgelaufene (Archivierte) Zertifikat. Führen Sie dazu die folgenden Schritte aus:

  1. Öffnen Sie das MMC-Snap-in (Microsoft Management Console), in dem Sie den Zertifikatspeicher auf dem IAS-Server verwalten. Wenn Sie noch nicht über ein MMC-Snap-in verfügen, um den Zertifikatspeicher aus anzuzeigen, erstellen Sie einen. Gehen Sie hierzu folgendermaßen vor:
    1. Klicken Sie auf Start, dann auf Ausführen, geben Sie MMC in das Feld Öffnen ein, und wählen Sie dann OKaus.

    2. Klicken Sie im Menü Konsole (im Menü Datei in Windows Server 2003) auf Snap-in hinzufügen/entfernen, und wählen Sie dann Hinzufügenaus.

    3. Wählen Sie in der Liste Verfügbare eigenständige Snap-Ins die Option Zertifikateaus, wählen Sie Hinzufügen, Computer Kontoauswählen, weiteraus, und wählen Sie dann Fertig stellenaus.

      Hinweis

      Sie können dem MMC-Snap-in auch das Zertifikat-Snap-in für das Benutzerkonto und das Dienstkonto hinzufügen.

    4. Wählen Sie Schließenaus, und wählen Sie dann OKaus.

  2. Wählen Sie unter Konsolenstammdie Option Zertifikate (lokaler Computer) aus.
  3. Wählen Sie im Menü Ansicht die Option Optionenaus.
  4. Aktivieren Sie das Kontrollkästchen Archivierte Zertifikate , und wählen Sie dann OKaus.
  5. Erweitern Sie Personal, und wählen Sie dann Zertifikateaus.
  6. Klicken Sie mit der rechten Maustaste auf das abgelaufene (Archivierte) digitale Zertifikat, wählen Sie Löschenaus, und klicken Sie dann auf Ja , um das Entfernen des abgelaufenen Zertifikats zu bestätigen.
  7. Beenden Sie das MMC-Snap-in. Sie müssen den Computer oder andere Dienste nicht neu starten, um dieses Verfahren ausführen zu können.

Weitere Informationen

Microsoft empfiehlt, dass Sie automatische Zertifikatanforderungen zum erneuern digitaler Zertifikate in Ihrer Organisation konfigurieren. Weitere Informationen finden Sie unter automatische Registrierung von Zertifikaten in Windows XP