Resumo

  • O MI.ACMEDelegationMethod autoriza uma conta da CDN a jusante a pedir um certificado delimitado, enquanto a própria CDN gera e guarda o par de chaves.
  • Objeto de delegação, validação da CSR e emissão pela CA comprovam etapas específicas. Não comprovam que o DNS chegou ao parque certo, que cada PoP ativou a credencial ou que o HTTP devolveu o objeto esperado.
  • Cancelamento STAR e revogação não-STAR encerram autoridade em ritmos diferentes. A operação precisa de recibos independentes da autorização até a observação externa.

Um certificado pode estar certo e o serviço, errado. Um PoP ainda usa a credencial anterior; outro copiou a nova, mas sua regra de SNI escolhe o certificado padrão; alguns resolvedores seguem o CNAME antigo; o nó que conclui TLS serve um objeto incorreto por falha de cache. Nada disso torna falsa a assinatura do certificado.

Publicado na trilha de padrões do IETF em fevereiro de 2024, o RFC 9538 trata de uma necessidade concreta. Quando uma CDN a montante delega HTTPS por redirecionamento DNS, a CDN a jusante precisa de um certificado para o nome do provedor de conteúdo. Em vez de copiar uma chave privada de longo prazo entre organizações, o modelo usa o RFC 9115: a jusante cria a chave, e o Identity Owner a montante limita o pedido.

Quatro campos iniciam o processo

acme-delegation traz a URL HTTPS do objeto vinculado à conta a jusante; time-window, o intervalo de validade. A presença de lifetime indica STAR, com certificados curtos e autorrenováveis; a ausência indica não-STAR. lifetime-adjust ajusta a duração STAR. O tipo consta no registro CDNI da IANA, apoiado pelos RFCs 8006, 8008 e 7336.

Esses campos não carregam inventário de nós, confirmação de instalação, impressão digital por região, observação DNS, teste SNI ou digest do conteúdo. “Delegação anunciada” não significa “entrega pronta”.

A conta prova permissão para solicitar

No RFC 9115, o Name Delegation Consumer é pré-cadastrado. Com a chave da conta, obtém um objeto com modelo de CSR, gera seu par de chaves e apresenta a solicitação. O Identity Owner confere nomes e extensões e usa a própria conta na CA conforme o ACME do RFC 8555.

A chave duradoura a montante não entra no parque a jusante, mas a conta delegada vira um controle crítico. Nessa perna, autenticação da conta e política pré-configurada substituem o desafio ACME comum. Uma CSR válida comprova aderência ao modelo, não implantação.

O RFC 5280 cobre o caminho X.509; o RFC 9525, a identidade de serviço; o RFC 8446, TLS 1.3; e o RFC 6066, SNI. Eles ajudam a decidir se a identidade apresentada é aceitável. Não atestam a resposta HTTP.

DNS continua sendo outra alavanca

O objeto pode carregar CNAME; o RFC 9538 admite futura extensão para SVCB/HTTPS. Em qualquer caso, o mapeamento do nome ao serviço é um estado separado. O titular pode manter controle exclusivo da zona. CAA restringe CAs e o RFC 8557 pode restringir conta e método ACME. Isso reduz poder de emissão, mas não comprova propagação nem destino.

É preciso guardar a alteração autoritativa, RRset e TTL, observar de várias redes e vincular cada endereço ao inventário. O número de série do certificado não contém esse mapa.

STAR e não-STAR usam relógios distintos

No RFC 8739, certificados STAR são curtos e renovados automaticamente. O Identity Owner cancela emissões futuras, mas o último certificado segue válido até expirar. O registro do incidente precisa conter cancelamento, última emissão, download, ativação e expiração.

No modo não-STAR, há revogação ACME. A montante pode solicitá-la; a jusante, dona da chave, pode conseguir agir diretamente numa emergência. A aceitação pela CA não remove configuração de todos os nós. Certificate Transparency torna a emissão visível, não a implantação ou retirada. As orientações do RFC 9325 também não substituem sondas.

Recibos que preservam a realidade

O dossiê deve separar: mandato do provedor; conta e escopo; objeto e modelo de CSR; CSR, chave e ordem; certificado, SANs e cadeia; DNS autoritativo e observado; inventário, impressão ativa e regra SNI; por fim, testes TLS e HTTP de redes independentes. Renovação e término percorrem a mesma cadeia.

“Emitido, ainda não instalado”, “92% dos PoPs convergiram” e “STAR cancelado; restam 47 minutos de validade” orientam ações. Um único status “seguro” apaga a fronteira.

O RFC 9538 não promete prova de ponta a ponta. O erro nasce quando o operador transforma um artefato de coordenação em testemunha da realidade em execução.

Fontes e limites

O status pode ser conferido na página do RFC Editor, no histórico do IETF e nos errata. A análise usa também os RFCs 9538, 9115, 8739, 8555, 8006, 8008, 7336, 9460, 9325, 9525, 5280, 8659, 8557, 8446, 6066 e 9162. Não foi examinado um incidente, parque ou captura de uma CDN identificada.