aethercert
Dokumentation

IIS: SSL-Zertifikat austauschen (Bindungen und SNI)

SSL-Zertifikat im IIS austauschen: PFX mit Import-PfxCertificate importieren, HTTPS- und SNI-Bindungen umstellen, HTTP.sys verstehen und das Ergebnis prüfen.

IIS-Websites nutzen HTTPS-Bindungen, die letztlich zu SSL-Bindungen in HTTP.sys werden. Ein Zertifikatstausch bedeutet: PFX in den Speicher des lokalen Computers importieren und in jeder betroffenen Bindung den Zertifikats-Hash ändern. Der Import allein lässt das alte Zertifikat aktiv.

Voraussetzungen

  • Sie brauchen das PFX-Kennwort und ein Zertifikat mit privatem Schlüssel, der EKU Serverauthentifizierung und SANs für jeden Hostnamen der Bindung.
  • Notieren Sie IP-Adresse, Port, Hostname, SNI-Einstellung, Zertifikatspeicher und den alten Fingerabdruck der Website. Exportieren Sie applicationHost.config oder legen Sie ein IIS-Konfigurations-Backup an.
  • Prüfen Sie, ob der zentrale Zertifikatspeicher (Centralized Certificate Store, CCS) aktiv ist. CCS wählt eine PFX-Datei anhand des Hostnamens aus und braucht einen anderen Ablauf.
  • Planen Sie Tests über jeden Load Balancer und direkt gegen jeden IIS-Knoten.

IIS-Bindungen und HTTP.sys

Eine normale IIS-Bindung ist durch IP, Port und optional einen Hostnamen bestimmt. Mit SNI erlaubt der Hostname im TLS-ClientHello mehrere Zertifikate auf derselben IP und demselben Port. Ohne SNI kann jede IP:Port-Kombination nur ein Zertifikat haben. IIS schreibt die Bindung für HTTP.sys; Sie verwalten sie normalerweise über den IIS-Manager oder das Modul WebAdministration, nicht durch separates Bearbeiten mit netsh http.

Anwendungen, die HTTP.sys außerhalb von IIS selbst hosten, sind ein anderer Fall. Sie legen ihre IP:Port- oder Hostname:Port-Bindung eventuell direkt mit netsh http add sslcert an; eine Änderung an einer IIS-Website ändert an dieser Anwendung nichts.

Zertifikat Schritt für Schritt austauschen

  1. Importieren Sie die PFX-Datei unter Zertifikate (Lokaler Computer) > Eigene Zertifikate > Zertifikate oder per PowerShell:

    $password = Read-Host "PFX password" -AsSecureString
    $cert = Import-PfxCertificate -FilePath C:\secure\site.pfx `
      -CertStoreLocation Cert:\LocalMachine\My -Password $password
    $thumbprint = $cert.Thumbprint

    Haben Sie über die Konsole importiert, lesen Sie den Fingerabdruck mit Get-ChildItem Cert:\LocalMachine\My | Format-Table Thumbprint,Subject,NotAfter aus. Sichern Sie vorher die IIS-Konfiguration: %windir%\system32\inetsrv\appcmd add backup "before-cert".

  2. Wählen Sie im IIS-Manager den Server und öffnen Sie Serverzertifikate. Prüfen Sie, ob das neue Zertifikat vorhanden ist und das erwartete Ablaufdatum hat.

  3. Wählen Sie Sites > <Website> > Bindungen und bearbeiten Sie genau die https-Bindung. Behalten Sie IP-Adresse, Port, Hostname und die Einstellung Servernamenanzeige erforderlich (SNI) bei, wählen Sie das neue Zertifikat aus und speichern Sie.

    Alternativ per PowerShell für eine bestehende Bindung:

    Import-Module WebAdministration
    $site = "Default Web Site"
    $hostName = "www.example.com"
    $binding = Get-WebBinding -Name $site -Protocol https -Port 443 -HostHeader $hostName
    $binding.AddSslCertificate($thumbprint, "My")
  4. Wiederholen Sie das für jede Bindung und jeden Webserver-Knoten. Ein für eine Website gewähltes Zertifikat gilt nicht automatisch für eine andere. Für mehrere SNI-Sites auf einmal:

    foreach ($h in "www.example.com","shop.example.com","api.example.com") {
      (Get-WebBinding -Protocol https -Port 443 -HostHeader $h).AddSslCertificate($thumbprint, "My")
    }

    "My" ist der Speicher Eigene Zertifikate des lokalen Computers.

  5. Zentraler Zertifikatspeicher (CCS): Die Bindung hat kein eigenes Zertifikat; IIS lädt die nach dem Hostnamen benannte PFX-Datei von der CCS-Freigabe - www.example.com.pfx, bei Wildcards _.example.com.pfx - mit dem Kennwort, das auf dem Server unter Zentralisierte Zertifikate hinterlegt ist. Ersetzen Sie diese Datei auf der Freigabe durch die neue PFX-Datei mit demselben Kennwort. Alle Server, die die Freigabe nutzen, übernehmen sie; prüfen Sie, ob jeder die Freigabe weiterhin lesen kann.

  6. HTTP.sys nach der Änderung prüfen:

    Get-ChildItem IIS:\SslBindings | Format-Table IPAddress,Port,Host,Thumbprint
    netsh http show sslcert

Produktspezifische Hinweise

Die Änderung einer normalen IIS-HTTPS-Bindung gilt für neue TLS-Handshakes und erfordert in der Regel kein Recycling des Anwendungspools, keinen IIS-Neustart und keinen Serverneustart. Bestehende TLS-Verbindungen können die vorher ausgehandelte Sitzung weiter nutzen. Vermeiden Sie iisreset als Routineschritt: Es unterbricht alle IIS-Websites auf dem Server.

Speichert eine Anwendung Zertifikatsinformationen oberhalb von IIS zwischen, folgen Sie der Anleitung dieses Produkts. Exchange beschreibt zum Beispiel Fälle, in denen bei Layer-4-Load-Balancing ein IIS-Neustart für das Authentifizierungs-Cookie von Outlook im Web empfohlen wird. Das ist Exchange-Verhalten, keine allgemeine Anforderung von IIS-Bindungen.

Bei einer Anwendung mit eigener HTTP.sys-Bindung ermitteln Sie zuerst deren dokumentierte AppID und Bindung. Ein typischer Austausch behält alle vorhandenen Optionen bei:

netsh http show sslcert hostnameport=service.example.com:443
netsh http delete sslcert hostnameport=service.example.com:443
netsh http add sslcert hostnameport=service.example.com:443 `
  certhash=<new-thumbprint> certstorename=MY appid={<existing-app-id>}

Zwischen Löschen und Hinzufügen gibt es einen kurzen Moment ohne Bindung. Machen Sie das nur für eine bekannte HTTP.sys-Anwendung außerhalb von IIS und übernehmen Sie deren Einstellungen für Clientzertifikate, Sperrprüfung und SNI.

Neues Zertifikat prüfen

Testen Sie den Hostnamen statt nur der Server-IP, damit SNI die richtige Bindung wählt:

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

Prüfen Sie Fingerabdruck, SANs, Ablaufdatum und die mitgelieferte Zwischenzertifikatskette. Testen Sie jeden Knoten, indem Sie den Hostnamen vorübergehend auf diesen Knoten auflösen oder einen Wartungspool am Load Balancer nutzen.

Rollback

Wählen Sie an jeder Bindung wieder das alte Zertifikat - im IIS-Manager oder mit (Get-WebBinding -Protocol https -Port 443 -HostHeader <host>).AddSslCertificate("<alter-fingerabdruck>", "My") - oder stellen Sie die Sicherung mit %windir%\system32\inetsrv\appcmd restore backup "before-cert" wieder her. Testen Sie erneut den tatsächlichen Hostnamen. Behalten Sie altes Zertifikat und privaten Schlüssel, bis jede Bindung, jeder Knoten, jeder Health Check und jede abhängige Anwendung geprüft ist.

Häufige Probleme

  • Das Zertifikat wurde in den Speicher des aktuellen Benutzers importiert oder hat keinen privaten Schlüssel.
  • SNI oder der Hostname wurden beim Bearbeiten der Bindung versehentlich geleert.
  • Eine zweite Website ohne SNI belegt bereits dieselbe IP:Port-Kombination.
  • Es wurde IIS geändert, obwohl die Anwendung eine eigene HTTP.sys-Bindung hat.
  • Die Website liefert das richtige Zertifikat, aber ohne Zwischenzertifikat.
  • Ein Load Balancer leitet noch auf einen nicht aktualisierten Knoten.

Zertifikatstausch mit aethercert automatisieren

Das aethercert-Deployment-Ziel für IIS importiert das Zertifikat in den Windows-Speicher und legt die gewählte HTTPS-Bindung an bzw. aktualisiert sie. Dabei bleibt die Abgrenzung erhalten: automatisiert werden IIS-Bindungen, keine beliebigen HTTP.sys-Registrierungen anderer Hersteller.

Unter Deployment-Ziele finden Sie die Felder dieser Vorlage, die Voraussetzungen auf dem Host und den Stand der Verifizierung.

Quellen

Auf dieser Seite