Summary

  • El borrador del grupo HTTP sobre certificados secundarios de servidor, versión 03, actualizado el 2 de noviembre de 2026, sigue siendo un Internet-Draft. Propone una trama SERVER_CERTIFICATE para que un servidor HTTP/2 o HTTP/3 demuestre, después de establecer TLS, que posee la llave de un certificado adicional.
  • Ambos extremos deben anunciar compatibilidad. El autenticador exportado de RFC 9261 vincula la prueba a la sesión TLS existente; el cliente aún debe juzgar si el certificado y el servidor sirven para el segundo origen.
  • La sección 7.3 describe el problema de salida: cambiar el CNAME dirige las conexiones nuevas a otro lugar, pero el proveedor antiguo puede seguir ofreciendo el certificado secundario del sitio a través de conexiones abiertas para otros sitios. La gestión de esa persistencia queda en manos del proveedor y su cliente.

Imaginemos que una editorial abandona su empresa de alojamiento. Modifica el alias DNS y observa que las conexiones nuevas llegan al sustituto. Un lector, sin embargo, mantiene una conexión HTTP/2 con otro sitio atendido por la empresa anterior. Esa empresa aún dispone del certificado de la editorial y lo envía por la conexión existente. Si el navegador acepta esa prueba como autoridad suficiente, una petición posterior del sitio trasladado puede tomar la ruta vieja. Es una prueba hipotética del riesgo señalado por el borrador.

La ventaja técnica se entiende. HTTP/2 y HTTP/3 permiten reutilizar una conexión entre orígenes cuando el servidor está autorizado para cada uno. El certificado presentado en el saludo TLS puede cubrir varios nombres. Pero un operador puede preferir certificados separados para cada cliente, con renovaciones y revocaciones independientes. El borrador mantiene esa separación administrativa y comparte el transporte. La pregunta decisiva pasa a ser quién demuestra que la segunda web todavía pertenece a esa conexión.

Una conexión adquiere otra identidad

El mecanismo exige un acuerdo visible. Cliente y servidor envían SETTINGS_HTTP_SERVER_CERT_AUTH con valor 1; sin los dos anuncios no pueden usar el intercambio. Después, el servidor puede mandar una trama SERVER_CERTIFICATE en cualquier momento. En HTTP/2 va por el flujo 0 y en HTTP/3 por el flujo de control. Dentro viaja un autenticador exportado que demuestra posesión de la llave privada correspondiente al certificado adicional, vinculada a la sesión TLS. Una copia del certificado por sí sola no aportaría esa prueba.

El cliente valida el autenticador y examina si el certificado sirve para el origen solicitado. Los fallos producen respuestas distintas. Un autenticador inválido es un error de conexión. Un certificado caducado, revocado o insuficiente se rechaza como credencial; el borrador recomienda intentar una conexión nueva con un servidor autorizado. El transporte compartido puede estar sano aunque el segundo origen sea inadmisible. Medir únicamente el éxito de la conexión ocultaría esa diferencia.

La sección de seguridad muestra un riesgo más agudo. Si se compromete la llave de un certificado secundario, a un servidor malicioso le basta con atraer al cliente a cualquier sitio HTTPS bajo su control antes de presentar la credencial robada de otro origen. El borrador recomienda consultar DNS para el segundo nombre si el cliente habría hecho esa consulta durante el saludo inicial. Si no consulta DNS, una señal alternativa como la trama ORIGIN puede reforzar la decisión. Poseer la llave y recibir hoy el tráfico de un dominio son hechos distintos.

El DNS se muda; la conexión sigue abierta

La sección 7.3 aborda la salida corriente de un proveedor, sin llave robada. El propietario cambia el CNAME. Las nuevas conexiones alcanzan al sucesor. El proveedor anterior continúa recibiendo conexiones para otros clientes y puede mantener configurado el certificado secundario del sitio que se fue. Desde esas conexiones compartidas puede seguir reclamando ese origen. El borrador considera coherente ese comportamiento con la configuración del antiguo proveedor, aunque probablemente choque con la voluntad del dueño.

El protocolo propuesto no ofrece una orden que cierre por sí sola esa vía; pide que los proveedores expliquen el riesgo a sus clientes.

Salir de un proveedor requiere entonces más que editar DNS. Hay que saber quién conserva la llave privada, qué servidores ofrecen el certificado secundario, cuándo se retira o revoca y qué prueba de autoridad vuelve a pedir el cliente. Una captura de la nueva respuesta DNS no muestra las peticiones que aún viajan por conexiones antiguas. Una lista de conexiones abiertas tampoco revela el destino final de cada petición. Las dos pruebas deben encontrarse.

El borrador prohíbe dar por validado un certificado secundario antiguo tras reanudar una sesión TLS. El servidor puede presentarlo otra vez y forzar una nueva evaluación. Durante una conexión, el conjunto de certificados aceptados puede cambiar mientras se procesa una petición; el cliente debe estar preparado para revisar su estado de autorización. El ahorro de conexiones se paga con un estado de confianza más móvil.

Las fuentes oficiales no ofrecen un censo de despliegues ni un incidente medido de migración. Una prueba controlada que reúna DNS, conexiones abiertas, tramas de certificado y destinos de las peticiones permitiría establecer el resultado. La decisión operativa ya es concreta: retirar la ruta del certificado secundario con el mismo cuidado que el alias DNS. Cambiar el letrero de la calle no inutiliza la llave que quedó en el edificio anterior.

Borrador HTTP · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336