Summary

  • O rascunho do grupo HTTP sobre certificados secundários de servidor, revisão 03, atualizado em 2 de novembro de 2026, ainda é um Internet-Draft. Ele propõe um quadro SERVER_CERTIFICATE para um servidor HTTP/2 ou HTTP/3 provar, após a conexão TLS, que possui a chave do certificado de outro site.
  • As duas pontas precisam anunciar suporte. O autenticador exportado do RFC 9261 vincula a prova à sessão TLS existente; o cliente ainda decide se o certificado e o servidor servem para a segunda origem.
  • A seção 7.3 descreve a armadilha na saída: a mudança do CNAME direciona conexões novas ao sucessor, mas o provedor antigo pode continuar oferecendo o certificado secundário por conexões abertas para outros sites. O provedor e o cliente precisam encerrar essa persistência.

Imagine uma editora trocando de hospedagem. Ela altera o CNAME e vê novas conexões chegar ao sucessor. Um leitor, porém, mantém uma conexão HTTP/2 com outro site atendido pelo provedor antigo. Esse provedor ainda tem o certificado da editora e o apresenta na conexão existente. Se o navegador aceitar a prova como autoridade suficiente, uma solicitação posterior ao site migrado pode voltar pela rota velha. A sequência serve para testar o risco indicado no rascunho.

O benefício técnico é fácil de entender. HTTP/2 e HTTP/3 permitem reutilizar uma conexão para várias origens quando o servidor tem autoridade sobre cada uma. Um certificado no início de TLS pode incluir vários nomes, mas um provedor pode preferir certificados separados, renováveis ou revogáveis por cliente. O rascunho preserva essa separação e compartilha o transporte. A conta pendente é saber se a segunda origem ainda pertence àquela conexão hoje.

Uma conexão ganha outra identidade

O mecanismo começa com um acordo explícito. Cliente e servidor enviam SETTINGS_HTTP_SERVER_CERT_AUTH com valor 1. Sem os dois anúncios, o certificado secundário não pode ser usado. Depois, o servidor pode enviar SERVER_CERTIFICATE a qualquer momento: no fluxo 0 do HTTP/2 ou no fluxo de controle do HTTP/3. O quadro contém um autenticador exportado que prova a posse da chave privada correspondente ao certificado adicional, vinculada à sessão TLS. Uma cópia do certificado, isoladamente, não prova quem segura a chave nessa conexão.

O cliente valida o autenticador e examina o certificado para a origem pretendida. Falhas distintas pedem respostas distintas. Autenticador inválido é erro de conexão. Certificado vencido, revogado ou insuficiente é uma credencial recusada; o rascunho recomenda tentar outra conexão com servidor autorizado. A conexão compartilhada pode continuar saudável enquanto o segundo site é rejeitado. Uma métrica que só conte conexões bem-sucedidas esconde essa divisão.

A seção de segurança mostra o risco mais agudo. Se a chave de um certificado secundário for comprometida, um servidor malicioso só precisa levar o cliente a algum site HTTPS sob seu controle antes de apresentar a credencial roubada para outra origem. O rascunho recomenda consultar DNS para esse segundo nome quando o cliente teria consultado DNS na conexão original. Sem a consulta, outra indicação de autoridade, como o quadro ORIGIN, pode reforçar a decisão. Possuir a chave e receber o tráfego atual do domínio são fatos diferentes.

O DNS vai embora; a conexão fica

A seção 7.3 descreve uma migração comum, sem chave roubada. O proprietário muda o CNAME e as conexões novas chegam ao novo provedor. O antigo continua recebendo conexões de outros clientes e pode manter configurado o certificado secundário do site que saiu. Ele ainda pode reivindicar aquela origem nessas conexões compartilhadas. O rascunho considera esse comportamento compatível com a configuração do provedor, embora provavelmente contrarie a intenção do dono. O protocolo proposto não traz um comando que apague essa persistência; recomenda que os provedores avisem seus clientes.

Sair de um provedor exige uma sequência de comprovantes. Quem guarda a chave privada? Quais servidores ainda apresentam o certificado secundário? Quando o certificado foi retirado ou revogado? O cliente repete a verificação de autoridade da segunda origem? A nova resposta DNS mostra para onde irão conexões novas, não as solicitações em conexões antigas. A lista de conexões abertas também não mostra sozinha onde cada pedido terminou. As duas trilhas precisam ser confrontadas.

O rascunho impede ainda que o cliente mantenha como validado um certificado secundário antigo depois da retomada de uma sessão TLS. O servidor pode apresentá-lo novamente, exigindo nova decisão. Durante uma conexão, o conjunto de certificados aceitos pode mudar enquanto uma solicitação é processada; o cliente precisa reavaliar sua autorização. A economia de conexões desloca trabalho para o estado de confiança.

As fontes oficiais não trazem contagem de adoção nem incidente medido de migração. Um teste controlado com DNS, conexões abertas, quadros de certificado e destino das solicitações estabeleceria o resultado. A decisão prática já é clara: desativar o caminho do certificado secundário com o mesmo rigor usado na troca do alias DNS. A placa na rua muda; a chave do prédio antigo continua funcionando até ser retirada.

Rascunho HTTP · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336