Summary

  • Der HTTP-Entwurf zur sekundären Serverzertifikatsprüfung, Revision 03, wurde am 2. November 2026 aktualisiert und ist weiter ein Internet-Draft. Er schlägt einen SERVER_CERTIFICATE-Frame vor, mit dem ein HTTP/2- oder HTTP/3-Server nach dem TLS-Aufbau den Schlüssel zu einem weiteren Website-Zertifikat nachweisen kann.
  • Beide Seiten müssen Unterstützung anzeigen. Der exportierte Authenticator aus RFC 9261 bindet den Nachweis an die bestehende TLS-Sitzung; der Client muss zusätzlich entscheiden, ob Zertifikat und Server für die zweite Herkunft zulässig sind.
  • Abschnitt 7.3 benennt das Ausstiegsproblem: Ein neuer CNAME lenkt neue Verbindungen um, doch der bisherige Anbieter kann das sekundäre Zertifikat auf Verbindungen für andere Websites weiter anbieten. Anbieter und Kunde müssen diese fortwirkende Möglichkeit beenden.

Eine Verlagsseite wechselt den Hoster. Nach der CNAME-Änderung erreichen neue Verbindungen den Nachfolger. Im Browser eines Lesers besteht jedoch noch eine HTTP/2-Verbindung zu einer anderen Seite beim bisherigen Hoster. Dieser hat das Zertifikat der Verlagsseite weiterhin und sendet es über die vorhandene Verbindung. Wenn der Client den Nachweis schon als ausreichende Berechtigung wertet, kann eine spätere Anfrage zur umgezogenen Seite beim alten Anbieter landen. Dieses gedachte Verfahren prüft den vom Entwurf beschriebenen Mechanismus.

Der Nutzen ist greifbar. HTTP/2 und HTTP/3 erlauben die Wiederverwendung einer Verbindung für mehrere Origins, sofern der Server für jeden zuständig ist. Ein TLS-Zertifikat kann mehrere Namen enthalten. Ein Hoster möchte jedoch oft die Zertifikate seiner Kunden getrennt erneuern und widerrufen. Der Entwurf erlaubt getrennte Zertifikate auf gemeinsamem Transport. Die Einsparung wirft eine neue Frage auf: Wer bestätigt, dass die zweite Website heute noch über diese Verbindung laufen soll?

Eine Verbindung erhält eine zweite Identität

Zuerst handeln Client und Server die Fähigkeit ausdrücklich aus. Beide senden SETTINGS_HTTP_SERVER_CERT_AUTH mit Wert 1. Ohne beide Signale darf die zusätzliche Zertifikatsprüfung nicht eingesetzt werden. Danach kann der Server jederzeit einen SERVER_CERTIFICATE-Frame schicken: bei HTTP/2 auf Stream 0, bei HTTP/3 auf dem Kontrollstream. Darin liegt ein exportierter Authenticator, der den Besitz des privaten Schlüssels zum zusätzlichen Zertifikat innerhalb dieser TLS-Sitzung beweist. Eine bloße Zertifikatskopie könnte das nicht leisten.

Der Client prüft den Authenticator und danach das Zertifikat für die angeforderte Website. Unterschiedliche Fehler haben unterschiedliche Folgen. Ein ungültiger Authenticator ist ein Verbindungsfehler. Ein abgelaufenes, widerrufenes oder unpassendes Zertifikat ist eine zurückgewiesene Berechtigung; der Entwurf empfiehlt dann eine neue Verbindung zu einem zuständigen Server. Die gemeinsame Verbindung kann also funktionieren, während die zweite Website abgelehnt wird. Eine reine Erfolgsquote für TLS-Verbindungen verschleiert genau diese Grenze.

Der Sicherheitsabschnitt zeigt einen schärferen Fall. Wird ein sekundäres Zertifikat samt Schlüssel entwendet, muss ein böswilliger Server den Client nur noch zu irgendeiner HTTPS-Seite unter eigener Kontrolle bringen. Dort kann er den gestohlenen Nachweis für eine andere Herkunft vorlegen. Der Entwurf empfiehlt für sekundäre Namen eine DNS-Prüfung, wenn der Client sie beim ursprünglichen TLS-Aufbau vorgenommen hätte. Ohne DNS kann ein anderes Autoritätssignal, etwa ein ORIGIN-Frame, die Entscheidung stützen. Schlüsselbesitz und heutige Netzroute sind getrennte Tatsachen.

DNS zieht weiter, die alte Verbindung bleibt

Abschnitt 7.3 braucht keinen gestohlenen Schlüssel. Der Eigentümer ändert den CNAME; neue Verbindungen gehen zum Nachfolger. Der bisherige Anbieter erhält weiter Verbindungen für andere Kunden und kann das sekundäre Zertifikat der fortgezogenen Seite noch konfiguriert haben. Auf solchen gemeinsamen Verbindungen kann er die Seite weiterhin beanspruchen. Der Entwurf nennt dies ein Verhalten entsprechend seiner Konfiguration, das dem Willen des Website-Eigentümers aber wahrscheinlich widerspricht. Das geplante Protokoll besitzt keinen eingebauten Schalter gegen diese Dauerwirkung; Anbieter sollen ihre Kunden vorher darüber aufklären.

Ein Ausstieg braucht deshalb mehrere Belege. Wer hat den privaten Schlüssel? Welche Server bieten das Zertifikat noch an? Wann wird es aus der Konfiguration entfernt oder widerrufen? Prüft der Client die Zuständigkeit für die zweite Website erneut? Eine frische DNS-Antwort zeigt nur den Weg neuer Verbindungen. Eine Liste alter Verbindungen zeigt allein noch nicht, wo einzelne Anfragen endeten. Beides muss mit Frame- und Anfrageprotokollen zusammengeführt werden.

Der Entwurf verbietet zudem, ein früheres sekundäres Zertifikat nach einer TLS-Sitzungswiederaufnahme weiter als validiert zu betrachten. Der Server kann es erneut vorlegen, worauf der Client neu entscheidet. Während eine Anfrage läuft, kann sich die Menge akzeptierter Zertifikate verändern; der Client muss seinen Berechtigungszustand gegebenenfalls neu bewerten. Weniger Verbindungen bedeuten mehr beweglichen Vertrauenszustand.

Die amtlichen Quellen nennen weder eine Zahl eingeführter Systeme noch einen gemessenen Vorfall beim Providerwechsel. Ein kontrollierter Wechsel mit DNS-, Verbindungs-, Zertifikats- und Anfrageprotokollen würde den Ausgang zeigen. Die unmittelbare Betriebspflicht ist klar: Der sekundäre Zertifikatsweg muss ebenso sorgfältig stillgelegt werden wie der DNS-Alias umgestellt wird. Das Straßenschild wechselt; der Schlüssel im alten Gebäude bleibt, bis ihn jemand zurücknimmt.

HTTP-Entwurf · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336