Windows Server 2025 / HTTPS in IIS einrichten und das Zertifikat vom Client prüfen

HTTPS in IIS benötigt ein zum angeforderten Namen passendes Zertifikat, den zugehörigen privaten Schlüssel auf dem Server und eine HTTPS-Bindung mit diesem Zertifikat. Prüfen Sie zusätzlich Clientvertrauen, Gültigkeit, Sperrprüfungsbedingungen und das tatsächlich ausgelieferte Zertifikat, besonders nach einer Erneuerung.

Namen, Schlüssel, Vertrauen und Bindung getrennt prüfen

HTTPS schützt HTTP-Verkehr mittels Transport Layer Security (TLS), dem Protokoll zur Transportsicherheit. Der Server legt ein Zertifikat vor, das seine Identität mit einem öffentlichen Schlüssel verbindet; der Client prüft Namen, Gültigkeit und Vertrauenskette. Der private Schlüssel bleibt auf dem Server und ermöglicht den Nachweis des Schlüsselbesitzes. Subject Alternative Name (SAN) ist die Erweiterung für zulässige Namen; hier muss sie web.lab.example.test enthalten.

IP-Zugriff ist kein Namenszugriff: Ein DNS-SAN für web.lab.example.test bestätigt nicht automatisch 172.24.50.30. Die TLS-Dienstidentitätsnorm RFC 9525 verwendet SAN-Kennungen. Eine Übereinstimmung nur im Common Name reicht nicht als Nachweis. Der .test-Name gehört zu diesem internen Labor; reale Dienste benötigen kontrollierte Namen und eine geeignete Zertifizierungsstelle (CA). Die HTTPS-Anleitung für IIS trennt Zertifikat und Bindung. Ihre historischen SSL-Beispiele sind keine Empfehlung, veraltete Protokolle einzuschalten.

Zertifikat für einen isolierten Test erstellen

Prüfen Sie zunächst LabSite mit web.lab.example.test, die Auflösung nach 172.24.50.30 und die erwartete HTTP-Seite. Verwenden Sie nur isolierte WEB1 und CLIENT1 ohne öffentliche Freigabe. Das selbstsignierte Zertifikat ist ein Test: Aussteller und Inhaber beziehen sich hier auf dasselbe Zertifikat; Clients vertrauen ihm nicht automatisch. Es ersetzt keine produktive Ausstellung, Prüfung oder Schlüsselverwaltung. Erfassen Sie vorher Bindungen, Regeln und vorhandenen Zustand beider Zertifikatspeicher.

Führen Sie die Zeilen lokal auf WEB1 in erhöhter Windows PowerShell einzeln aus. Scheitert die Erstellung, stoppen Sie und verwenden keinen alten Wert aus labCertificate. Dokumentieren Sie den Fingerabdruck Thumbprint des neuen Objekts außerhalb der Sitzung. Ein Monat Laufzeit ist eine Laborentscheidung; AddMonths(1) bedeutet einen Kalendermonat, nicht eine CA-Richtlinie oder stets 30 Tage. New-SelfSignedCertificate beschreibt DNS-Namen in SAN und den Computerspeicher:

$labCertificate = New-SelfSignedCertificate -DnsName 'web.lab.example.test' -CertStoreLocation 'Cert:\LocalMachine\My' -FriendlyName 'LabSite HTTPS test' -NotAfter (Get-Date).AddMonths(1)
$labCertificate | Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey

Öffnen Sie auf WEB1 certlm.msc → Eigene Zertifikate → Zertifikate und suchen Sie den genau erfassten Fingerabdruck. Prüfen Sie SAN, Serverauthentifizierungszweck, Aussteller, Datumswerte und zugeordneten privaten Schlüssel. Erwartet wird HasPrivateKey = True; das bestätigt nur eine Schlüsselzuordnung, nicht dass der Dienst den Schlüssel verwenden kann. Die Windows-Anleitung zur Zertifikatspeicherverwaltung unterscheidet lokalen Computer und aktuellen Benutzer. Prüfen Sie vor einer Wiederholung vorhandene Testobjekte, statt gleichnamige Kopien anzusammeln. Ein Anzeigename identifiziert das Zertifikat nicht eindeutig.

HTTPS-Bindung auf Port 8443 hinzufügen

1. Aktualisieren Sie im IIS-Manager → WEB1 → Serverzertifikate die Ansicht und suchen Sie das neue Zertifikat anhand von Fingerabdruck und Datumswerten, nicht nur Anzeigename.
2. Öffnen Sie LabSite → Bindungen → Hinzufügen und wählen Sie https, IP 172.24.50.30 und Port 8443. Prüfen Sie zuvor vorhandene Kombinationen und Dienste auf Konflikte.
3. Tragen Sie web.lab.example.test ein und aktivieren Sie Servernamensanzeige erforderlich. Verwenden Sie nicht versehentlich den StatusSite-Namen.
4. Wählen Sie LabSite HTTPS test und bestätigen Sie den auf WEB1 erfassten Fingerabdruck. Fehlt es oder sein Schlüssel, prüfen Sie Speicher und Objekt statt eines ähnlich benannten Ersatzes.
5. Prüfen Sie vollständige Kombination, Duplikate und Sitezustand. Behalten Sie HTTP 8080 während dieser Übung unverändert, um die Zugriffe unterscheiden zu können.
6. Erstellen Sie nach Prüfung des Domänenprofils auf WEB1 nur bei freiem Namen Lab-IIS-HTTPS-8443: wf.msc → Eingehende Regeln → Neue Regel → Port → TCP lokal 8443 → Verbindung zulassen → nur Domäne. Begrenzen Sie unter Eigenschaften → Bereich Remote-IP-Adressen auf 172.24.50.0/24. Prüfen Sie andere Regeln und Richtlinien; erweitern Sie nicht alle Profile und schalten Sie die Firewall nicht aus.

Server Name Indication (SNI), die Servernamenangabe, übermittelt den angeforderten Namen bei der TLS-Aushandlung und hilft bei der Zertifikatauswahl für gemeinsame IP und Port. Prüfen Sie die Bindungs- und SNI-Attribute. Port 8443 trennt diese Übung von HTTP 8080; der übliche HTTPS-Port ist 443. SNI erzeugt weder Vertrauen noch einen anderen SAN. Fehlende Clientunterstützung berechtigt nicht zum Abschalten der Zertifikatsprüfung.

Vertrauen und tatsächlich geliefertes Zertifikat auf CLIENT1 prüfen

Öffnen Sie auf CLIENT1 https://web.lab.example.test:8443/. Vor dem Vertrauenseintrag ist für dieses selbstsignierte Zertifikat eine Warnung zu erwarten; Warnungen können aber auch andere Ursachen haben. Umgehen Sie sie nicht als vermeintlichen Erfolgsnachweis und geben Sie keine Zugangsdaten ein. Prüfen Sie das vorgelegte Zertifikat, sofern der Browser das ohne Fortfahren erlaubt, gegen Fingerabdruck, Namen und Gültigkeit des WEB1-Protokolls. Bei anderem Fingerabdruck oder unklarer Identität stoppen Sie und prüfen die Bindung vor einer Vertrauensänderung.

1. Wählen Sie auf WEB1 in certlm.msc → Eigene Zertifikate → Zertifikate anhand des Fingerabdrucks das Testzertifikat → Alle Aufgaben → Exportieren. Wählen Sie Nein, privaten Schlüssel nicht exportieren und eine öffentliche .cer-Datei mit neuem Namen und Pfad ohne Überschreiben.
2. Übertragen Sie diese .cer über einen vertrauenswürdigen Laborweg nach CLIENT1. Erstellen oder verteilen Sie keine PFX mit privatem Schlüssel: Der Client benötigt das öffentliche Zertifikat, nicht den Serverschlüssel.
3. Öffnen Sie die öffentliche Datei und vergleichen Sie den Fingerabdruck mit dem auf WEB1 erfassten Wert über einen vertrauenswürdigen Weg, unabhängig von einer Datei unbekannter Herkunft. Prüfen Sie Namen und Gültigkeit. Bei Abweichung nicht importieren.
4. Öffnen Sie auf CLIENT1 als späterer Testbenutzer certmgr.msc → Vertrauenswürdige Stammzertifizierungsstellen → Zertifikate → Alle Aufgaben → Importieren. Wählen Sie nur die geprüfte .cer und bestätigen Sie Aktueller Benutzer und diesen Speicher. Notieren Sie Fingerabdruck und Bereich zum späteren Entfernen. Importieren Sie nicht auf Produktivgeräten oder per Domänenrichtlinie.
5. Schließen und öffnen Sie den Browser desselben Benutzers erneut und rufen Sie https://web.lab.example.test:8443/ auf. Prüfen Sie warnungsfreie Verbindung, Fingerabdruck und Seiteninhalt, nicht nur einen geöffneten Tab.

Ein Stammzertifikat verändert, was in diesem Kontext als vertrauenswürdig gilt. Importieren Sie ausschließlich das selbst erstellte und geprüfte Testzertifikat, nie ein unbekanntes zum Entfernen einer Warnung. Bleibt der Fehler, prüfen Sie SAN, Client- und Serverzeit, Gültigkeit, tatsächlich gelieferten Fingerabdruck sowie Browser- oder Organisationsrichtlinien. Aktueller Benutzer betrifft diesen Benutzerkontext und belegt nicht das Verhalten anderer Benutzer oder Dienste. Verteilen Sie das Testvertrauen weder per Domänenrichtlinie noch durch Wechsel in den globalen Speicher, nur damit die Übung funktioniert.

Test-NetConnection -ComputerName web.lab.example.test -Port 8443

TcpTestSucceeded: True zeigt nur eine erfolgreiche TCP-Verbindung auf 8443, nicht TLS-Aushandlung, Namen, Kette oder Seiteninhalt. Prüfen Sie im Browser das tatsächliche Zertifikat und den Zertifizierungspfad, denselben erfassten Fingerabdruck und die erwartete LabSite-Seite. Warnungsfreiheit zusammen mit diesen Prüfungen ist etwas anderes als das Fortfahren trotz Warnung. Der Test bestätigt auch keine funktionierende Sperrprüfung einer realen CA.

Bindungen bei Erneuerung und Bereinigung kontrollieren

Ein neu ausgestelltes oder importiertes Ersatzobjekt im Speicher garantiert nicht, dass IIS es ausliefert. Prüfen Sie nutzbaren neuen Schlüssel, Namen, Kette, Zweck und Gültigkeit, ändern Sie die vorgesehene Sitebindung und bestätigen Sie von einem getrennten Client neuen Fingerabdruck und Seite. Erfassen Sie zuvor alte Bindung und Fingerabdruck. Behalten Sie das alte Zertifikat, bis Abhängigkeiten und Rückkehrbedarf geklärt sind; ein abgelaufenes oder gesperrtes Zertifikat ist kein gültiges Rückfallziel. Ersetzen Sie nicht pauschal alle Bindungen anhand gleicher Anzeigenamen.

• Ordnen Sie Verantwortung, Erneuerungsverfahren und Fehlerwarnungen zu, die Ausstellungs- und Bereitstellungsfehler erkennen, nicht nur das Ablaufdatum.
• Planen Sie vor Ablauf Zeit für Freigabe, Installation, Bindungswechsel und Clientprüfung ein. Eine Warnung ohne Verantwortlichen vervollständigt den Ablauf nicht.
• Halten Sie für Zertifikate und Richtlinien mit erforderlicher Sperrprüfung die tatsächlichen Sperrlisten- oder Statusantwortstandorte erreichbar. Erfinden Sie keine solchen Pfade für dieses selbstsignierte Testobjekt und deaktivieren Sie keine globalen Prüfungen als Fehlerumgehung.
• Überwachen Sie bei automatisierter Erneuerung auch Bindungszuordnung und tatsächlich geliefertes Zertifikat. Ein neues Speicherobjekt bestätigt noch nicht dessen Nutzung durch den Verkehr.

Entfernen Sie zur Bereinigung nur die hinzugefügte HTTPS-Bindung von LabSite und Lab-IIS-HTTPS-8443. Prüfen Sie andere Bindungs- und Dienstabhängigkeiten, bevor Sie das Testzertifikat anhand des Fingerabdrucks auf WEB1 im lokalen Computerspeicher unter Eigene Zertifikate entfernen. Öffnen Sie auf CLIENT1 certmgr.msc und entfernen Sie nur den eigenen hinzugefügten Eintrag unter Aktueller Benutzer → Vertrauenswürdige Stammzertifizierungsstellen mit demselben Fingerabdruck. Prüfen Sie den Bereich, falls eine Ansicht Einträge aus einem anderen Speicher erbt. Löschen Sie keine fremden Stammzertifikate oder ähnlich benannten Zertifikate. Entscheiden Sie getrennt, ob HTTP 8080 bestehen bleibt oder eine bereits geprüfte HTTPS-Weiterleitung geplant wird. Eine HTTPS-Bindung leitet HTTP nicht automatisch um und entfernt es nicht.