Resumo

  • draft-ietf-acme-profiles-02 permite anunciar perfis locais e registrar a escolha no Order; continua sendo Internet-Draft, não RFC nem vocabulário universal.
  • O nome atesta uma seleção aceita. Elegibilidade, controle do identificador, conformidade do DER, instalação e confiança do cliente permanecem recibos separados.
  • A operação segura preserva Directory e documentação da época do pedido, inspeciona o certificado emitido e observa o que cada endpoint realmente entrega.

O painel registra profile: "tlsserver" e encerra o job com sucesso. Mesmo assim, um nó entrega o certificado antigo, o novo contém um EKU inesperado e parte dos clientes rejeita a cadeia. O profile não responde a esses fatos porque sua função termina antes deles.

draft-ietf-acme-profiles-02, de 28 de agosto de 2026, é trabalho do ACME Working Group na trilha de padrões. Ele resolve uma lacuna do RFC 8555: CAs oferecem classes diferentes de certificados, porém faltava uma superfície comum para anunciar e selecionar a política. A nota do autor lista dois servidores e sete clientes; Let’s Encrypt documenta produção. São evidências de implementação, não status final nem pesquisa completa de adoção.

Um seletor no namespace da CA

O servidor publica meta.profiles em sua Directory. Cada nome curto aponta para documentação legível. O cliente pode enviar o nome em newOrder; o Order aceito o repete.

Os nomes não são globais. classic ou shortlived pode significar outra coisa em outra CA. A URL não precisa conter um esquema de todos os campos X.509; pode até ser data URI. O valor seleciona uma política local, não transporta um certificado de significado.

Essa limitação mantém o protocolo enxuto. O cliente expressa intenção sem modelar o produto na CSR. A CA expõe opções sem API proprietária. A escolha acompanha o Order. Produtos, preços e regras internas continuam locais.

O contexto deve ser preservado: endpoint, hash da Directory, horário, par TLS, bytes da descrição e termos da conta. Guardar somente tlsserver é guardar um índice sem a tabela.

A política sai da CSR, a chave pública não

No RFC 8555, identificadores entram no Order e a CSR chega no finalize. Uma CSR carrega extensões diversas; copiá-las sem política forte amplia riscos de parsing e emissão.

Profiles transfere a seleção para o Order. Para essa decisão, o texto trata como irrelevantes os campos da CSR além de SAN e Subject Public Key. A CA monta o certificado conforme sua política.

Não significa que a CSR inteira deixou de importar. A chave e os SANs continuam essenciais. Construção, assinatura, chain, política e transparência continuam sob responsabilidade da CA. A melhoria é uma fronteira mais clara.

Pedido explícito e default do servidor

Se o cliente envia o profile, sua mensagem assinada demonstra intenção da conta. O servidor ainda avalia compatibilidade.

Se o cliente omite, o draft recomenda ao servidor escolher e associar um profile. Nesse caso, o valor é decisão do servidor, não opção ativa do assinante.

Registre origem da seleção, versão e configuração do cliente, conta, request, resposta, versão de política e autoridade de mudança. Assim uma adoção antecipada não se confunde com alteração silenciosa do default.

Os cronogramas Let’s Encrypt mostram a diferença: profiles opt-in introduzem EKU mais restrito ou vida menor antes da mudança de classic. As duas rotas são válidas, mas atribuem controle de modo distinto.

Elegibilidade não é controle do domínio

O servidor deve rejeitar combinação incompatível, como tipo de identificador inadequado ou conta fora da allowlist. O erro proposto é invalidProfile.

Isso não substitui autorização ACME. A conta pode usar profile privado e ainda não controlar o domínio. Completar DNS-01 não concede direito a um profile restrito.

Separe três recibos: fundamento da elegibilidade; prova de cada identificador; decisão de emissão. External Account Binding, contrato ou allowlist apoiam o primeiro; challenges, o segundo; registro da CA e certificado, o terceiro.

Exceção não anunciada exige autoridade

O servidor deveria rejeitar profile não anunciado, mas pode aceitar exceções. O texto menciona acordo privado e substituição durante revogação em massa.

Isso protege continuidade e significa que ausência na Directory não prova invalidade. Um Order excepcional deve apontar contrato ou incidente, contas, prazo, restrições, aprovador, objetivo e retirada. Privado não é abuso; sem rastreabilidade é impossível de auditar.

Há dois relógios na retirada

O profile pode sair da Directory enquanto Orders anteriores continuam vivos. Se a CA já não emitir no finalize, deve responder invalidProfile; idealmente espera os Orders expirarem.

Registre início e fim do anúncio, último Order, expiração máxima, última emissão, renovações, substituto e exceções. Sem esse mapa, o cliente atribui a falha tardia à rede ou CSR.

Também há drift sob nome estável. Validade, EKU, reutilização e chain podem mudar. Congele a definição por Order e valide de novo a cada renovação.

O DER é a prova de conformidade

Order aceito é compromisso de política. Certificado é saída verificável.

Compare SANs, tipos, algoritmo de chave, Key Usage, EKU, Basic Constraints, políticas, criticidade, validade, issuer, assinatura, chain, serial, codificação, CT e campos proibidos com predicado versionado. Vincule o DER ao Order, autorizações e chave da CSR.

Documentação humana ajuda a escolher, mas é fraca para automação. A CA poderia publicar manifesto verificável; esta é proposta operacional, não requisito do draft. O objetivo é testar promessa local sem centralizar catálogo.

Repita no renewal. Mesmo nome não garante mesma versão, duração ou chain. Validar só a resposta ACME ignora a credencial.

CT, CAA e chain são controles independentes

CT mostra submissão ao log; não mostra profile escolhido, conformidade ou deploy. CAA limita emissores e parâmetros próprios; não seleciona profile nem enumera o DER.

Uma CA pode oferecer uma chain e o cliente construir outra. A política do profile não obriga o trust store. Essas observações somam valor porque permanecem independentes.

Emissão não instala o certificado

Certificado e chave precisam chegar ao endpoint. Balanceadores, regiões, secrets, sidecars e processos antigos produzem deploy parcial.

Associe hash do DER e da chave a cada destino. Observe externamente o certificado servido, SNI, chain, ativação e retirada do anterior. Teste clientes representativos.

A cadeia completa é descobrir -> preservar -> selecionar -> qualificar -> autorizar -> vincular Order -> finalizar -> inspecionar -> implantar -> observar -> renovar. Cada etapa pode suceder e a próxima falhar.

O caso Let’s Encrypt mostra uma ferramenta de migração

Let’s Encrypt define profile como características da validação e do certificado final. Usuários comuns recebem seleção automática; necessidades específicas podem optar.

Na mudança de EKU, tlsserver retirou Client Authentication antes do default, enquanto tlsclient ofereceu janela temporária. Na redução de validade, profiles de 45 e seis dias precedem mudanças gerais.

Isso demonstra implantação escalonada. Também mostra que nome precisa de data: EKU, validade, reutilização e disponibilidade seguem calendários distintos. Não prova sucesso de todo assinante nem suporte universal.

Um recibo liga escolha e realidade

O recibo reúne Directory, documentação, origem, conta, autoridade de configuração, identificadores, chave, elegibilidade, autorizações, Order, CSR, DER, serial, issuer, chain, CT, teste de conformidade, alvos, observação, clientes, renovação, exceção e rollback.

“O Order repetiu o nome” é observação. “O DER atende à versão X” é teste. “O endpoint serviu o DER” é nova observação. Resultado de negócio vem depois.

O protocolo permanece mínimo e cada parte conserva as provas de sua decisão. O nome não precisa governar tudo para ser útil.