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.configoder 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
-
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.ThumbprintHaben Sie über die Konsole importiert, lesen Sie den Fingerabdruck mit
Get-ChildItem Cert:\LocalMachine\My | Format-Table Thumbprint,Subject,NotAfteraus. Sichern Sie vorher die IIS-Konfiguration:%windir%\system32\inetsrv\appcmd add backup "before-cert". -
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.
-
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") -
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. -
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. -
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 -showcertsPrü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
Windows-Zertifikatspeicher
PFX mit Import-PfxCertificate in den Zertifikatspeicher des lokalen Computers importieren, HasPrivateKey prüfen, Zugriff auf den privaten Schlüssel erteilen und Dienste prüfen.
Microsoft Exchange Server
Exchange-Zertifikat erneuern: PFX mit Import-ExchangeCertificate importieren, IIS, SMTP, POP und IMAP zuweisen, Connectoren anpassen und jedes Protokoll prüfen.