Resumo

  • No intercâmbio comum de CMP sobre HTTP, a RFC 9811 exige 200 OK com uma resposta CMP no corpo. Esse êxito externo não substitui o PKIStatus, que pode registrar aceitação, concessão com alterações, rejeição ou espera.
  • Uma trilha confiável liga autoridade, HTTP, PKIMessage protegido, transactionID, sondagem, confirmação, armazenamento e validação pelos sistemas dependentes, sem fingir que todos são o mesmo evento.

O erro mais sedutor na automação de certificados é aquele que já vem pintado de verde: 200 OK.

A RFC 9811, publicada em julho de 2025 na série normativa do IETF, define como transportar o Certificate Management Protocol por HTTP. O formato é restrito. Um PKIMessage codificado em DER vai no corpo de um POST com application/pkixcmp. Quando a requisição HTTP comum é bem-sucedida, o servidor devolve a resposta CMP no corpo de uma resposta 200; nenhum outro código 2xx deve ocupar esse papel.

Essa precisão não transforma o HTTP em autoridade certificadora. Ela fixa o recibo externo para que o protocolo interno continue decidindo.

Uma resposta, dois vocabulários

A RFC 9810 define estados CMP como accepted, grantedWithMods, rejection e waiting. Portanto, quatro operações diferentes podem compartilhar o mesmo 200: uma concessão exata, uma concessão que exige inspeção das mudanças, uma recusa ou uma decisão que ainda não terminou.

Uma métrica única de sucesso HTTP perde justamente a informação que governa o próximo passo. O erro inverso é abandonar o corpo assim que aparece 4xx ou 5xx. A RFC 9811 exige que o cliente consiga tratar uma resposta CMP presente no conteúdo de respostas 2xx, 4xx e 5xx. Um erro na camada externa pode trazer a explicação interna mais específica e verificável.

O processamento correto acumula evidência. Recebe-se o HTTP, controlam-se tipo e tamanho, decodifica-se DER, verifica-se a proteção CMP e o remetente, associa-se o transactionID e só então se interpreta corpo, estado e motivo de falha. Cada etapa permite a próxima; nenhuma responde sozinha por toda a operação.

Falta de resposta é incerteza, não ausência comprovada

Segundo a RFC 9811, sem uma resposta HTTP que confirme o recebimento, o cliente deve presumir que a mensagem CMP não foi entregue com sucesso. É uma regra conservadora de transporte. Ela impede a alegação de entrega sem recibo, mas não enxerga o estado interno do servidor.

A conexão pode cair depois que a autoridade leu ou processou a mensagem. Para o cliente, a entrega ficou sem confirmação; para a CA ou RA, uma transação talvez já exista. Repetir imediatamente com outro identificador pode duplicar a operação. Não repetir pode deixar uma renovação necessária inacabada.

A retomada precisa preservar o transactionID, o hash da mensagem original, a autoridade, o tipo de operação e o limite de tempo. Quando o fluxo CMP admitir continuação ou sondagem, use esse caminho. Quando não houver como conciliar, registre “incerto” e escale. Criar uma nova transação para limpar o painel apenas transfere a incerteza para a infraestrutura de chaves.

Estado sobre um transporte sem estado

Algumas operações PKI atravessam vários pares de requisição e resposta. O HTTP pode tratar cada viagem separadamente, enquanto o transactionID une as mensagens em uma transação CMP. Uma vez estabelecido, o valor deve permanecer nos intercâmbios posteriores. Um cliente não deve manter duas transações simultâneas com o mesmo identificador para o mesmo servidor.

A RFC 9810 recomenda 128 bits pseudoaleatórios na criação pelo cliente. O servidor pode exigir unicidade do par {cliente, transactionID} ou do identificador isolado, conforme a forma como reconhece clientes. Uma colisão que impeça a associação correta deve produzir transactionIdInUse.

Correlação não é autenticação. O campo não prova a identidade do solicitante, a autorização para um perfil, a integridade da mensagem nem a idempotência do sistema de negócio. Proteção CMP, nonces, identificadores de pedido e política local têm funções próprias. O registro deve reuni-los, sem promover um número de rastreamento a credencial de autoridade.

waiting continua depois do fim da chamada

O estado waiting mostra a fronteira de forma direta. O corpo da solicitação ainda não foi processado e o cliente envia pollReq. A CA ou RA responde com o resultado final quando estiver pronto; caso contrário, devolve pollRep com checkAfter. O cliente espera pelo menos o intervalo indicado antes de consultar novamente.

O atraso pode refletir carga do backend, transporte offline entre entidades PKI ou aprovação humana em uma RA. O ciclo HTTP terminou; a decisão organizacional não.

A automação deve guardar o responsável, a próxima hora permitida, a idade da transação, o limite de escalada e a validade restante do certificado atual. Consultar antes de checkAfter não acelera uma aprovação e consome a capacidade que pode estar faltando. Tratar espera como rejeição cria pedidos paralelos. Tratar como aprovação fecha um controle sem que o certificado exista.

Emissão não é necessariamente encerramento

A RFC 9810 define certConf para o cliente aceitar ou rejeitar certificados devolvidos e pkiconf para a confirmação da autoridade. Se a CA alterou campos pedidos, a entidade final precisa examinar o certificado efetivo. grantedWithMods não autoriza instalação automática sem comparação.

O histórico completo separa a resposta protegida, o estado, a impressão digital, as diferenças em relação ao pedido, a confirmação, o fechamento do protocolo, a gravação no repositório, a ativação no serviço e a validação por quem confia. A mesma impressão digital conecta esses registros, mas não prova que cada etapa ocorreu.

Um banco de emissão pode registrar o novo objeto enquanto o balanceador ainda apresenta o anterior. A ferramenta de implantação pode estar verde enquanto clientes relevantes recusam cadeia, nome, finalidade ou validade. Um serviço em funcionamento também pode ocultar a perda da confirmação CMP. Estado em execução e fechamento protocolar exigem evidências diferentes.

Anúncios usam outro contrato de recibo

Para anúncios de atualização de chave de CA, certificado, revogação ou CRL, a RFC 9811 inverte os papéis: o servidor CMP atua como cliente HTTP e o receptor não envia resposta CMP. Ele devolve uma resposta HTTP vazia.

201 Created indica que a informação foi armazenada ou já existia. 202 Accepted indica apenas aceitação para processamento posterior; o emissor pode esperar e tentar novamente até obter confirmação de processamento. Esses significados não devem contaminar o fluxo comum, no qual 200 transporta o resultado CMP.

Sem autenticação e proteção adequadas, a declaração de processamento do anúncio não merece confiança, e o projeto PKI não pode depender de uma entrega garantida. O código só vira evidência dentro de um contexto de origem e proteção.

/.well-known/cmp define o caminho, não a autoridade

Servidores CMP que usam HTTP ou HTTPS precisam aceitar o prefixo /.well-known/cmp. Segmentos adicionais podem distinguir operações, CAs ou perfis. O registro de Well-Known URIs da IANA lista cmp como sufixo permanente sob controle do IETF.

O caminho padroniza onde perguntar em uma origem; não descobre o host certo. A RFC 8615 deixa isso explícito e alerta que uma localização bem conhecida representa uma superfície de controle da origem. É preciso guardar a fonte da configuração, resolução, redirecionamentos, par TLS, remetente CMP protegido e política que liga essas identidades.

A RFC 9811 permite suporte a 3xx, mas recomenda cautela antes do seguimento automático. Um destino 301 malicioso e persistido pode afastar permanentemente o cliente do servidor correto. A conveniência do HTTP não pode mudar silenciosamente a âncora de confiança.

Um grafo de recibos

O dossiê mínimo preserva: CA ou RA esperada; URI configurada e final; redirecionamentos; identidade TLS; método, status, tipo e hashes HTTP; remetente, destinatário, tipo e proteção CMP; transactionID, nonces e identificador de solicitação; PKIStatus, falha, checkAfter; impressão digital, alterações, certConf e pkiconf; versão do repositório; ativação; retorno; e observação independente dos serviços relevantes.

Ele também registra limites. Sem resposta é entrega não confirmada. Com 200 é resposta recebida. Emitido é objeto criado. Instalado é estado local alterado. Uma conexão bem-sucedida é aceitação por um participante específico. Nenhum estágio deve fabricar o seguinte.

Running-Code Primacy coloca a prova final no cliente em execução, no estado da CA/RA, no repositório de chaves e nas transações dependentes. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption justifica uma camada comum precisa e estreita, sem absorver política, aprovação ou implantação. Reality Layers impede que verdades de camadas diferentes sejam esmagadas em um único símbolo.

A RFC 9811 não enfraquece 200 OK. Ela devolve honestidade ao recibo: a requisição HTTP funcionou e a resposta chegou. A decisão sobre o certificado continua lá dentro.

Fontes