Resumo

  • A RFC 9773 permite que uma autoridade certificadora recomende quando o cliente deve tentar renovar e que um novo pedido identifique o certificado anterior. A escolha aleatória do instante, o recuo, a alternativa de segurança, a emissão ACME e a implantação continuam sob controle local.
  • suggestedWindow, replaces aceito, pedido valid, download, registro em CT, arquivo instalado e certificado observado numa nova conexão TLS são evidências diferentes. Uma etapa não deve declarar a seguinte concluída.

“Renovado” é uma cadeia de entregas

O painel mostra uma palavra só: renovado. Na prática, ela pode encobrir uma longa sequência de entregas entre atores que não enxergam o mesmo sistema.

A autoridade certificadora escolhe a faixa de tempo que considera apropriada. O cliente escolhe um instante dentro dela. Outra marca temporal define quando consultar a informação novamente. O estado de erro limita uma nova tentativa. O serviço ACME emite o certificado. A automação local distribui os arquivos, valida a configuração e recarrega processos. Finalmente, uma conexão real revela qual certificado um ponto de terminação apresenta.

Se todas essas transições forem reduzidas a um campo chamado next_run ou a um indicador verde, a operação perde a causa do atraso. Não saberá se está aguardando uma nova consulta, o instante selecionado, o fim do recuo, a emissão, a implantação ou a convergência dos pontos de borda.

Considere uma frota que recebeu uma janela de vinte e quatro horas. A autoridade fez o que sua visão global permite: afastou o trabalho de um pico futuro e abriu espaço para distribuição. Mesmo assim, no próximo despertar comum dos agendadores, o gráfico sobe como uma parede.

Talvez os instantes tenham sido arredondados para o mesmo limite de cron. Talvez clientes incapazes de dormir até um horário exato tenham executado ao perceber que a escolha ocorreria antes do próximo despertar. Algumas instâncias podem ter perdido o estado de falha num reinício. Um orquestrador de frota pode ter reunido milhares de escolhas em uma única tarefa.

Esse é um cenário analítico, não a descrição de um incidente atribuído a uma CA específica. Ele mostra a pergunta central: quem tem autoridade sobre cada relógio, e qual evidência autoriza a passagem para o próximo estado?

O diretório publica uma fonte de orientação

Um servidor ACME que oferece ARI inclui uma URL renewalInfo no objeto de diretório. Para consultar um certificado, o cliente forma um identificador reproduzível: codifica em base64url o keyIdentifier da extensão Authority Key Identifier, acrescenta um ponto e codifica em base64url os bytes DER do número de série, retirando o preenchimento final. Em seguida, faz um GET não autenticado.

Essa construção permite que implementações independentes cheguem ao mesmo objeto. Ela não transforma a resposta em comando de implantação.

O RenewalInfo exige suggestedWindow.start e suggestedWindow.end. Os dois valores delimitam o período em que a autoridade recomenda tentar a renovação. Uma explanationURL opcional pode explicar balanceamento dinâmico ou a necessidade de antecipar uma revogação em massa.

Três distinções são indispensáveis.

A janela não é o período de validade X.509 e não altera notBefore nem notAfter. Não é uma resposta de revogação CRL ou OCSP. E a existência do recurso não prova que o cliente o buscou, aceitou a informação ou iniciou um pedido.

A autoridade pode colocar toda a janela no passado para recomendar ação imediata. Um cliente com relógio atrasado ainda pode interpretá-la como futura. Um cliente sem suporte a ARI não a verá. A visão central melhora a orientação, mas não produz adoção local.

A escolha aleatória pertence ao cliente

A RFC 9773 recomenda selecionar uniformemente um instante dentro da janela. Se já passou, o cliente tenta renovar imediatamente. Se consegue acordar no horário exato, espera. Se a escolha estiver antes do próximo despertar normal, age agora. Caso contrário, aguarda a próxima consulta de RenewalInfo e reavalia.

A CA não marca um compromisso exato para cada certificado. Para isso, precisaria conhecer a resolução do agendador, as janelas de manutenção e as regras de recuperação de cada assinante. A faixa comum coordena o conjunto sem assumir o controle da execução local.

Aleatoriedade, porém, não é uma garantia automática de distribuição. O instante selecionado deve persistir após reinícios. Caso contrário, o cliente pode sortear novamente a cada despertar e caminhar para um horário conveniente. Instâncias clonadas não devem compartilhar um estado pseudoaleatório que gere escolhas iguais. Uma resolução grosseira pode esmagar uma faixa ampla em poucos pontos. Um trabalho de frota não deve substituir escolhas por certificado por um único disparo global.

Clientes baseados em tarefas periódicas também precisam manter o histórico de falhas. Aumentar a frequência de consulta sem preservar contagem de erros e horário do último erro elimina o recuo. Um agendador sem memória transforma maior observabilidade em maior pressão sobre a CA.

Uma janela com end igual ou anterior a start é inválida. O cliente a trata como ausência de resposta utilizável e segue uma nova consulta ou o plano local alternativo. Uma origem esperada não dá autoridade a dados contraditórios.

Retry-After regula a nova consulta

Em ARI, Retry-After expressa o intervalo desejado até a próxima leitura de RenewalInfo, como mínimo e máximo solicitados, respeitando limites locais razoáveis e a prioridade do recuo por erro.

Ele não agenda o pedido de certificado.

Ao receber Retry-After: 21600, o cliente aprende uma cadência de seis horas para atualizar a informação. O instante escolhido dentro da janela permanece separado. Misturar os dois impede distinguir uma espera deliberada de uma visão antiga da orientação da CA.

Timeouts de conexão ou requisição e respostas 5xx são falhas temporárias; o cliente usa recuo exponencial com número limitado de tentativas. Quando se esgotam, ou diante de falha duradoura como Retry-After ausente ou inválido, objeto inválido, erro DNS, conexão recusada ou resposta não-5xx, ele volta depois de seis horas ou de outro valor local configurado.

A orientação operacional da Let’s Encrypt recomenda verificar ARI pelo menos duas vezes ao dia por certificado e manter uma alternativa baseada na validade restante. Trata-se de prática de uma CA, não de uma constante universal da RFC. O sistema deve registrar se um limite veio do protocolo, da autoridade ou do operador.

replaces cria linhagem, não recibo de implantação

ARI adiciona o campo opcional replaces ao pedido ACME. Ele usa o mesmo identificador e declara qual certificado anterior o novo pedido pretende substituir.

A linhagem ajuda a autoridade a reconhecer renovações, aplicar prioridade ou política de limites e acompanhar sucessores de certificados afetados por um incidente. O servidor verifica conta e identificadores segundo sua política. Se outro pedido não inválido já marcou o anterior como substituído, responde HTTP 409 com alreadyReplaced.

A aceitação continua sendo uma evidência da emissão. Não prova que o cliente baixou o sucessor, verificou a chave, entregou o arquivo ao balanceador, recarregou o processo ou deixou de apresentar o certificado antigo.

Até a palavra substituído no registro da CA deve ser lida no sentido do ACME: o pedido novo tem uma relação reconhecida com o anterior. Transformá-la numa afirmação sobre infraestrutura que a autoridade não observa amplia indevidamente a evidência.

valid não carrega o certificado no serviço

A RFC 8555 continua governando a emissão. O cliente cria um pedido, satisfaz autorizações de identificadores quando necessário, envia a CSR à URL de finalização, acompanha o processamento e baixa o certificado da URL preenchida no pedido.

ready significa que os requisitos foram satisfeitos e a finalização é esperada. processing indica emissão em andamento. valid significa que a CA emitiu e disponibilizou a URL. Um download bem-sucedido prova que os bytes chegaram ao cliente.

Nenhuma dessas etapas os coloca em uso.

Ainda existem custódia da chave, composição da cadeia, confirmação de correspondência, permissões, distribuição, validação de configuração, recarga, drenagem de conexões, réplica regional e reversão. Um arquivo novo pode coexistir com um processo antigo que nunca o reabriu. Uma região pode convergir enquanto outra mantém o antecessor.

Um estado explicável precisa de transições próprias:

  1. RenewalInfo obtido e validado;
  2. instante escolhido e persistido;
  3. pedido criado com a linhagem anterior;
  4. autorização e finalização concluídas;
  5. certificado baixado, impressão calculada e chave verificada;
  6. artefato entregue a destinos nomeados;
  7. configuração validada e processo recarregado;
  8. nova conexão local apresentando a impressão esperada;
  9. observação externa nos caminhos definidos;
  10. retirada do material anterior após período limitado de recuperação.

Um booleano renovado não simplifica essa cadeia. Ele apaga a localização da falha.

CT ilumina a emissão, não a borda ativa

A RFC 9162 descreve registros públicos de certificados TLS emitidos ou observados. Certificate Transparency permite auditar autoridades, detectar emissão inesperada e verificar o comportamento cumulativo dos logs.

Uma entrada CT é forte evidência de emissão ou envio ao log. Não é evidência de implantação.

Um pré-certificado pode ser registrado durante a emissão. Um terceiro pode enviar a cadeia. A entrada pode existir antes de o assinante baixar o resultado. O log não visita todos os pontos de terminação e não sabe qual balanceador possui a chave privada correspondente.

A conclusão correta é que o certificado ou pré-certificado entrou no mecanismo de transparência segundo suas regras. Para afirmar que o serviço público o apresenta, é preciso observar o serviço.

Uma nova negociação se aproxima do fato operacional

No TLS 1.3 com autenticação por certificado, o servidor envia sua cadeia na mensagem Certificate, prova a posse da chave por CertificateVerify e conclui a transcrição autenticada com Finished.

Uma conexão nova, sem depender de sessão anterior, permite observar qual impressão um ponto de terminação apresenta naquele momento. Ela deve ser comparada ao resultado baixado e repetida por família de endereços, região, nome SNI, camada de terminação e caminho relevante.

A evidência continua limitada. Um caminho IPv4 atualizado não prova IPv6. Um local anycast não prova todos os locais. Uma sonda interna pode terminar antes da camada pública. Uma sessão retomada pode não oferecer a troca completa pretendida.

“No horário T, o ponto E apresentou a impressão F pelo caminho P numa negociação nova” é uma afirmação auditável. “Implantado globalmente” exige um plano de observação que realmente cubra o escopo.

Um registro causal por certificado

Preserve, separados e ligados:

  • identificador ARI, diretório ACME e última consulta correta;
  • início e fim da janela, explicação, impressão da resposta e Retry-After;
  • instante escolhido, método, desvio do relógio, resolução e persistência;
  • limite alternativo, falhas, último erro e próximo horário permitido;
  • antecessor, conta, URL do pedido e resultado de replaces;
  • horários de autorização, finalização, emissão e download;
  • impressão, cadeia, correspondência de chave e local de custódia;
  • destinos, verificações, recargas e estado de reversão;
  • novas negociações por região, família de endereços e terminação;
  • retirada do antecessor e evidência que autorizou a retirada.

Chaves privadas, credenciais completas e topologia sem filtro não pertencem a uma superfície analítica geral. Impressões, identificadores controlados e recibos com responsável preservam causalidade sem ampliar a exposição de segredos.

A CA relata orientação e emissão. O cliente relata seleção e pedido. A implantação relata custódia e recarga. O ponto de terminação apresenta o certificado. O observador relata um caminho. Nenhuma camada precisa tomar emprestada a certeza da próxima.

O sistema em operação conclui a substituição

Publicar uma regra de coordenação não cria por si só realidade operacional. A realidade aparece quando participantes implementam, validam, implantam e usam a mudança.

A camada comum de ARI é estreita: anunciar o recurso, identificar o certificado, expressar uma janela, informar a cadência de consulta e nomear o antecessor. Ela não centraliza a agenda de implantação do assinante e não declara um serviço alterado.

A decisão local permanece no instante, no recuo e na alternativa. A adoção voluntária aparece quando o cliente implementa ARI e decide como integrá-lo. A primazia do código em funcionamento aparece no fim: o certificado se torna fato do serviço quando os pontos ativos o apresentam.

A autoridade controla a janela, não todos os relógios. O cliente controla a tentativa, não a emissão. A implantação controla a instalação, não todos os caminhos. Uma sonda controla sua observação, não toda a frota.

Separar essas autoridades não reduz a automação. Torna possível medi-la, interrompê-la e revertê-la.

Fontes