Summary

  • Le projet du groupe HTTP sur les certificats secondaires de serveur, version 03, mis à jour le 2 novembre 2026, reste un Internet-Draft. Il propose une trame SERVER_CERTIFICATE pour prouver, après l'établissement de TLS, la possession du certificat d'un autre site sur une connexion HTTP/2 ou HTTP/3.
  • Les deux côtés doivent annoncer leur prise en charge. L'authentificateur exporté du RFC 9261 lie la preuve de la clé à la session TLS existante ; le client décide encore si ce certificat et ce serveur conviennent au second site.
  • La section 7.3 décrit la sortie difficile : changer le CNAME dirige les nouvelles connexions ailleurs, mais l'ancien prestataire peut continuer à présenter le certificat secondaire du site sur des connexions ouvertes pour d'autres sites. Le texte confie ce problème de persistance au prestataire et à son client.

Imaginons un éditeur qui quitte son hébergeur. Il modifie l'alias DNS et voit les nouvelles connexions rejoindre le successeur. Un lecteur conserve toutefois une connexion HTTP/2 vers un autre site servi par l'ancien hébergeur. Celui-ci possède encore le certificat du site parti et l'envoie sur la connexion ouverte. Si le navigateur accepte cette preuve comme autorité suffisante, une demande ultérieure peut reprendre l'ancienne route. Cette séquence met à l'épreuve le risque décrit par le projet.

La promesse technique est nette. HTTP/2 et HTTP/3 peuvent réutiliser une connexion pour plusieurs origines si le serveur fait autorité pour chacune. Un certificat présenté pendant la poignée de main TLS peut couvrir plusieurs noms. Un hébergeur peut pourtant vouloir des certificats séparés, renouvelables et révocables par client. Le projet conserve cette séparation administrative sans renoncer à la connexion commune. Reste à déterminer à quel moment une autorité autrefois valable cesse de l'être.

Une connexion gagne une deuxième identité

Le mécanisme demande d'abord un accord explicite. Client et serveur envoient chacun SETTINGS_HTTP_SERVER_CERT_AUTH avec la valeur 1. Sans les deux annonces, l'échange de certificats secondaires ne démarre pas. Le serveur peut ensuite transmettre une trame SERVER_CERTIFICATE à tout moment : sur le flux 0 en HTTP/2, sur le flux de contrôle en HTTP/3. L'authentificateur exporté qu'elle contient prouve que le serveur possède la clé privée du certificat supplémentaire dans cette session TLS. La simple copie d'un certificat ne fournirait pas cette preuve.

Le client valide l'authentificateur puis examine le certificat pour l'origine demandée. Les échecs ont des conséquences différentes. Un authentificateur invalide est une erreur de connexion. Un certificat expiré, révoqué ou insuffisant est un refus de ce certificat ; le projet conseille alors au client d'essayer une nouvelle connexion vers un serveur autorisé. La connexion commune peut donc rester saine pendant que la seconde origine est rejetée. Un tableau de bord qui compte seulement les connexions réussies perd cette nuance.

La section sécurité expose un risque plus tranchant. Avec la clé d'un certificat secondaire compromise, un serveur malveillant a seulement besoin que le client visite un site HTTPS qu'il contrôle pour présenter ensuite cette clé au nom d'une autre origine. Le projet recommande de consulter le DNS pour ce second nom si le client l'aurait fait lors de la poignée de main initiale. Sans consultation DNS, un autre indice d'autorité, tel que la trame ORIGIN, peut renforcer la décision. Prouver la clé et vérifier la route actuelle sont deux opérations.

Le DNS change, la connexion reste

La section 7.3 traite une sortie ordinaire plutôt qu'une clé volée. Le propriétaire change le CNAME pour quitter un prestataire. Les nouvelles connexions partent vers le remplaçant. L'ancien prestataire reçoit encore des connexions pour ses autres clients et peut garder le certificat du site sortant dans sa configuration. Il peut alors revendiquer ce site sur ces connexions partagées. Le projet reconnaît que ce comportement correspond à la configuration du prestataire, tout en contredisant probablement l'intention du propriétaire.

Aucun message du protocole proposé ne règle cette persistance ; le texte demande aux prestataires de prévenir leurs clients.

Quitter un hébergeur devient donc une suite d'actes vérifiables. Qui détient encore la clé privée ? Quels serveurs l'offrent en certificat secondaire ? Quand le certificat est-il retiré ou révoqué ? Le client vérifie-t-il à nouveau l'autorité de la seconde origine ? Une capture de la nouvelle réponse DNS ne montre pas les demandes qui passent encore sur une ancienne connexion. Une liste des connexions ouvertes ne dit pas à elle seule où les demandes sont envoyées.

Le projet interdit aussi de considérer un certificat secondaire antérieur comme toujours validé après la reprise d'une session TLS. Le serveur peut le présenter à nouveau, ce qui impose une nouvelle décision. Pendant une connexion, l'ensemble des certificats acceptés peut changer alors qu'une demande est en cours ; le client doit pouvoir réévaluer l'autorisation de cette demande. L'économie de connexions déplace ainsi une partie du travail vers la gestion d'état et de confiance.

Les sources officielles ne donnent ni chiffre de déploiement ni incident mesuré de migration. Un changement contrôlé, observé à travers le DNS, les connexions ouvertes, les trames de certificat et les destinations des demandes, établirait le résultat. Dès maintenant, la consigne opérationnelle est concrète : retirer le chemin du certificat secondaire avec autant de soin que l'alias DNS. Déplacer l'enseigne de la rue ne rend pas la clé de l'ancien bâtiment inutilisable.

Projet HTTP · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336