Resumo

  • A Let’s Encrypt anunciou em 15 de outubro a passagem de quatro para seis perspectivas remotas. Em 27 de outubro, confirmou que seis já são usadas no ambiente de testes. Uma validação envolverá sete solicitações: a principal e seis remotas.
  • A tabela do CA/Browser Forum aceita uma não confirmação quando há de duas a cinco perspectivas remotas, e duas quando há seis ou mais. As perspectivas que confirmam devem cobrir duas regiões RIR. A entrada em produção está planejada para 10 de novembro, condicionada ao teste.

Quem viu a resposta?

O administrador de um site publica a resposta exigida para renovar seu certificado. Abre a página do próprio escritório e tudo parece certo. A autoridade certificadora precisa fazer uma pergunta mais incômoda: a mesma resposta aparece de outras redes? Se uma rota BGP for desviada, uma única máquina de validação pode chegar ao destino errado e receber uma resposta fabricada para ela. Depois, navegadores tratariam o certificado emitido como legítimo. É por isso que o caminho percorrido até a resposta faz parte da decisão.

A validação por múltiplas perspectivas distribui essa observação. Um ponto principal determina o resultado da prova de controle do domínio ou da consulta CAA; pontos remotos conferem se veem o mesmo. No aviso de 15 de outubro, a Let’s Encrypt disse que acrescentaria dois pontos aos quatro existentes. No dia 27, registrou no mesmo fio que o ambiente de testes já usa seis. O plano é levar a configuração à produção em 10 de novembro, caso o teste corra bem. Ainda falta, no fio verificado, um comunicado de que essa virada ocorreu.

As regras vigentes do CA/Browser Forum exigem no mínimo quatro perspectivas remotas desde 15 de junho de 2026 nos controles aplicáveis; a partir de 15 de dezembro serão pelo menos cinco. Também exigem que as perspectivas remotas que confirmem o ponto principal estejam em duas regiões de serviço RIR. O critério recai sobre quem deu a resposta concordante. Espalhar máquinas pelo mapa e receber todos os “sins” de uma única região não resolve a exigência.

O sexto ponto compra uma discordância

A tabela de quórum é curta e poderosa. Com dois a cinco pontos remotos distintos, apenas um pode não confirmar o resultado principal. Com seis ou mais, podem ser dois. Em um conjunto de seis, quatro respostas concordantes podem bastar mesmo com outras duas discordantes ou indisponíveis, desde que todas as condições restantes sejam cumpridas. Em um conjunto de cinco, também seriam necessárias quatro respostas concordantes, mas só haveria espaço para uma falha. A sexta observação amplia a tolerância a uma segunda falha sem reduzir o número de respostas favoráveis nesse exemplo.

Os pontos precisam ser realmente diferentes. As regras consideram duas perspectivas distintas quando há pelo menos 500 quilômetros em linha reta entre elas; cada remota também deve se distinguir da principal e das demais no quórum. Se a autoridade usar um conjunto para controle do domínio e outro para CAA, cada conjunto precisa passar sozinho. Compartilhar o mesmo cache DNS entre pontos destruiria a independência das respostas, por isso a norma proíbe reaproveitar resultados dessa forma. Uma nova tentativa pode ocorrer imediatamente, inclusive por outro método, mas os votos favoráveis da tentativa anterior ficam para trás.

Não dá para juntar as melhores respostas de várias rodadas e chamar isso de quórum.

O histórico operacional de 2024 confirma que quatro perspectivas remotas entraram em produção em 27 de março daquele ano. O anúncio atual acrescenta o estado de teste com seis. A Let’s Encrypt associa a mudança à resistência contra ataques de roteamento BGP. A regra traduz essa intenção em um mecanismo: enganar um caminho não basta quando outros pontos independentes e a exigência de duas regiões têm de concordar.

Um erro precisa ter sobrenome

Se o quórum ou a condição regional falhar, o CA/Browser Forum manda a autoridade não emitir o certificado. Para o dono de um site, isso pode surgir como uma renovação automática frustrada. A resposta ao desafio pode funcionar na máquina que ele administra e falhar a partir de uma rede distante. Foi a resposta errada, uma conexão inacessível, um CAA que veda a emissão ou a falta de confirmação em duas regiões? Cada hipótese aponta para uma ação diferente.

A norma permite repetir a verificação, mas exige novas confirmações. A Let’s Encrypt pode resolver uma falha transitória com outra tentativa; não pode transformar respostas antigas em crédito para a rodada seguinte. O diagnóstico precisa distinguir a falha do desafio da falha de uma perspectiva remota. Esconder tudo sob “validação falhou” deixa o cliente sem caminho para consertar o problema e o emissor sem uma boa trilha de decisão.

O fio público examinado não informa taxa de sucesso no teste, aumento de latência ou quantidade de renovações afetadas. Um anúncio datado da produção com a contagem final de perspectivas estabelecerá o próximo fato. Depois disso, resultados agregados das recusas mostrarão o preço e o benefício da sexta testemunha.

O CA/Browser Forum define a regra de contagem; a Let’s Encrypt escolhe e opera os pontos; o solicitante sofre a recusa quando o quórum não fecha. O certificado é o produto na ponta da linha. A votação invisível que o antecede é a decisão de governança.