Falhas de certificados TLS: procedimento de resposta para agentes

Um erro de certificado em uma chamada de API feita por um agente é um sinal para interromper a operação, não um simples incômodo de rede. A chamada pode transportar um bearer token, uma solicitação assinada, um registro de cliente ou instruções que alteram o estado de produção. Se o cliente não consegue estabelecer quem controla a outra ponta da conexão, não deve enviar nenhum desses dados.

Esse problema é mal administrado porque uma pessoa sob pressão vê um certificado expirado e recorre a uma opção insegura. Um agente autônomo torna esse atalho ainda mais perigoso. Ele pode repetir a chamada rapidamente, seguir uma instrução escondida em uma issue do repositório e repetir a mesma chamada insegura com mais de uma credencial. Um bom procedimento interrompe a execução, separa fatos de suposições e só restaura o acesso depois que alguém comprova que o endpoint pretendido voltou a ser o endpoint que recebe o tráfego.

Um aviso de certificado muda a decisão de confiança

O TLS cumpre duas funções que as pessoas frequentemente misturam. Ele criptografa o tráfego e verifica a identidade do servidor. Criptografia sem verificação de identidade apenas proporciona uma conversa privada entre um invasor e seu cliente.

A RFC 6125 descreve como uma aplicação compara a identidade de um serviço com um identificador de referência, geralmente o nome DNS que o cliente pretendia acessar. A RFC 5280 descreve a validação do caminho do certificado: o cliente constrói uma cadeia a partir do certificado final apresentado, passando pelos intermediários até chegar a uma âncora de confiança. As duas verificações importam. Um certificado pode ter uma assinatura válida e ainda pertencer a api-attacker.example, não a api.example. Ele pode conter o nome de host correto e ainda assim encadear até um emissor que sua organização nunca aprovou.

Para o tráfego de agentes, a consequência é concreta. Um bearer token injetado em uma solicitação HTTPS pode ser usado por quem termina a conexão. Uma solicitação assinada com uma credencial de cliente pode autorizar alterações de estado. Uma resposta de API enviada por um impostor pode instruir uma ação posterior ou contaminar o contexto de trabalho do agente. O fato de a solicitação estar criptografada não diminui nenhum desses riscos.

Trate estas mensagens como relevantes para a segurança até que a equipe estabeleça a causa:

• certificado expirado ou ainda não válido
• nome de host ou nome alternativo do assunto incompatível
• não foi possível obter o certificado do emissor local ou verificar o primeiro certificado
• certificado autoassinado na cadeia de certificados
• falha na verificação do certificado depois de uma alteração no proxy, no DNS ou na rede

Não classifique toda falha como um ataque ativo. Um certificado intermediário esquecido e o relógio errado de um notebook são falhas operacionais comuns. A resposta começa pela incerteza porque a mesma classe de erro também aparece quando alguém redireciona o tráfego ou instala um proxy de interceptação não aprovado.

Uma conexão TCP bem-sucedida prova apenas que algo respondeu em um endereço. Um handshake TLS bem-sucedido com a verificação desativada prova ainda menos. A verificação da identidade do servidor é o ponto em que uma chamada de API com credenciais ganha permissão para sair da máquina.

Interrompa a execução afetada antes de coletar pistas

A primeira ação operacional é impedir novas chamadas com credenciais para o destino que falhou. Suspenda o processo do agente, revogue sua sessão ativa se a camada de ações permitir revogação ou remova sua permissão para executar a ação. Faça isso antes de passar uma hora discutindo se o certificado parece familiar.

Preserve o erro original exatamente como ocorreu. Registre o nome de host e a porta completos, o método da solicitação sem o cabeçalho de autorização, o horário com fuso, o runtime e a versão do cliente e o processo que iniciou a chamada. Anote qual rede a máquina usou e se a falha começou depois de uma implantação, renovação de certificado, alteração de VPN, implantação de proxy, atualização de DNS ou mudança no gerenciamento do dispositivo.

Mantenha essas evidências fora de conversas informais se elas incluírem caminhos de clientes ou corpos de solicitações. Nunca cole cabeçalhos de autorização, cookies, chaves privadas de clientes ou arquivos completos de ambiente em um ticket de incidente. Uma investigação de certificado não justifica criar um segundo vazamento de segredo.

Use um registro curto do incidente que deixe a responsabilidade clara:

1. Nomeie uma pessoa responsável por interromper o agente e outra responsável pelo endpoint ou pelo caminho de rede.
2. Marque se a chamada havia chegado ao ponto de injeção de credenciais. Se sim, presuma que a credencial pode ter sido exposta até que o par TLS seja identificado.
3. Preserve o identificador da sessão do agente e o registro da ação que falhou, depois impeça novas tentativas automáticas para esse destino.
4. Defina um ponto de revisão para a restauração. A pessoa que precisa que a API funcione não deve ser a única a decidir que um novo certificado raiz é confiável.

Isso não é burocracia. Já vi equipes passarem a maior parte de um incidente testando comandos enquanto um worker em segundo plano continuava tentando acessar o mesmo endpoint com falha a cada poucos segundos. O trabalho de diagnóstico tornou-se parte da exposição. Interrompa o comportamento primeiro.

Não deixe o agente «corrigir» o problema de confiança editando configurações globais do runtime. Prompts que sugerem curl -k, verify=False, um pacote de CAs personalizado para tudo ou a verificação do Node.js desativada merecem a mesma resposta que um pedido para imprimir um token de API. O agente não consegue determinar se um certificado inesperado é uma alteração aprovada só porque uma busca na web diz que o erro é comum.

Preserve o certificado sem enviar um segredo

É possível inspecionar um certificado de servidor sem autenticar na API. Use um endpoint de integridade não autenticado, se existir, ou estabeleça um handshake e pare antes de qualquer solicitação da aplicação. Faça a verificação na mesma máquina e rede que registraram a falha, pois configurações de proxy, raízes de confiança corporativas e DNS dividido frequentemente variam entre máquinas.

Este comando solicita o nome do servidor pretendido por SNI, verifica o nome de host solicitado, mostra os certificados enviados pelo par e falha quando há um problema de verificação:

openssl s_client \\
  -connect api.example.com:443 \\
  -servername api.example.com \\
  -verify_hostname api.example.com \\
  -verify_return_error \\
  -showcerts < /dev/null

Um resultado limpo termina com uma saída semelhante a esta:

Verification: OK
Verify return code: 0 (ok)

Em caso de falha, salve a saída como evidência restrita do incidente. Os campos úteis incluem assunto, emissor, datas Not Before e Not After, nomes alternativos do assunto e cada certificado da cadeia. Os blocos PEM permitem que o responsável pelo endpoint compare o que sua máquina recebeu com o que o servidor deveria apresentar. São certificados públicos, mas trate o registro com cuidado, pois nomes de host e emissores internos ainda podem revelar detalhes da infraestrutura.

Em seguida, teste o comportamento normal do cliente sem um cabeçalho de autorização:

curl --verbose --fail --show-error \\
  https://api.example.com/health

O registro detalhado mostra a versão do TLS, o certificado selecionado e a mensagem de verificação. Redija os caminhos das solicitações se eles revelarem nomes de clientes. Não adicione -k para fazer o comando terminar com sucesso. A falha de verificação é a evidência de que você precisa.

Um erro comum de diagnóstico é omitir -servername. Muitos endpoints hospedados selecionam certificados com base no SNI e retornam um certificado padrão quando o cliente não o envia. Isso cria uma incompatibilidade de nome de host que nunca afetou o cliente real. Outro erro é usar openssl s_client sem -verify_hostname e tratar o resultado da cadeia como prova de que o nome de host correspondeu. Não é.

Registre o endereço resolvido separadamente com sua ferramenta normal de diagnóstico DNS. Não transforme a correspondência de endereço no teste inteiro. Grandes provedores usam legitimamente muitos endereços, enquanto um invasor pode controlar uma resposta DNS plausível. O nome do certificado, o caminho do emissor, o caminho da rede e o registro de alteração aprovado, juntos, contam a história.

Classifique a falha antes de escolher uma correção

Os erros de certificado parecem semelhantes em um log, mas exigem correções diferentes. Coloque as evidências em uma categoria antes de alterar a configuração de confiança. Caso contrário, a equipe resolve o erro visível e deixa intocada a falha original de roteamento ou implantação.

Um certificado expirado geralmente significa que o operador do endpoint não fez a renovação ou não implantou o novo certificado final. Compare o intervalo de validade do certificado capturado com um relógio confiável. Um erro de relógio pode fazer um certificado atual parecer expirado ou ainda não válido, portanto verifique o horário do cliente antes de pedir a um provedor que faça qualquer rotação.

Uma incompatibilidade de nome de host significa que o servidor não comprovou a posse do nome solicitado pelo cliente. As causas comuns são uma URL base de API errada, um erro de configuração de SNI, um host virtual padrão, DNS desatualizado ou um certificado de proxy para outro nome. Não aceite um nome alternativo só porque ele se parece com o nome pretendido. api.example.com e api.internal.example.com podem representar serviços e limites de confiança diferentes.

Um emissor desconhecido pode significar que falta ao cliente uma raiz privada ou um certificado intermediário legítimo. Também pode significar que um dispositivo de inspeção TLS não aprovado emitiu um certificado final substituto. Compare o emissor e a cadeia com as informações de implantação publicadas ou registradas pelo responsável pelo endpoint, usando um canal independente. Uma mensagem do mesmo sistema que produziu o erro não é uma confirmação independente.

Uma cadeia incompleta geralmente é responsabilidade do endpoint. Os servidores devem enviar o certificado final e os certificados intermediários necessários. Os clientes devem possuir previamente apenas suas raízes de confiança. Instalar um intermediário ausente localmente pode esconder a configuração quebrada do servidor em uma máquina e deixar todos os demais clientes com falha. Peça ao responsável pelo servidor que forneça a cadeia correta.

Um certificado final autoassinado exige suspeita adicional. Ele pode ser normal em um serviço interno de desenvolvimento, mas não oferece por si só uma prova pública de identidade. Uma CA privada gerenciada pode funcionar bem se os administradores distribuírem sua raiz por meio de um armazenamento de confiança aprovado para dispositivos ou workloads e registrarem quem controla essa CA. Um certificado autoassinado aleatório enviado por e-mail pelo responsável de um endpoint não é um programa de confiança.

A revogação de certificados exige cuidado. Muitos clientes não executam verificações de revogação online de forma confiável em todos os ambientes, e falhas de rede podem afetar essas verificações. Não declare que um certificado é seguro apenas porque um handshake básico retorna 0 (ok). Se um responsável informar que uma chave privada foi comprometida ou que um certificado foi revogado, bloqueie o destino, faça a rotação das credenciais expostas e providencie uma nova implantação.