Uma falha de federação atrás da Cloudflare não prova que o proxy removeu a assinatura HTTP. É preciso descobrir se a solicitação foi bloqueada na borda, se chegou ao servidor de origem e qual erro o relay registrou. Não desative a segurança de todo o domínio nem force TLS 1.3 como uma suposta correção universal.
Identificar em qual etapa a entrega falha
Registre o horário, o endpoint, o status HTTP e, quando disponível, o identificador da solicitação na Cloudflare. Compare os eventos de segurança com os registros do proxy de origem e do relay. A ausência de uma entrada no relay pode indicar que a solicitação nem chegou a ele.
Uma resposta HTML de desafio não é uma resposta ActivityPub válida. A documentação de páginas de desafio da Cloudflare explica que elas interrompem o fluxo normal e esperam um navegador. Uma integração entre servidores não deve ser diagnosticada como se fosse uma pessoa navegando no site.
Revisar bloqueios sem liberar o domínio inteiro
Se os registros mostrarem uma regra responsável por bloquear entregas legítimas, avalie uma correção restrita ao serviço e ao endpoint necessários. Preserve os demais controles e verifique o efeito com o responsável pela segurança. Não copie uma regra que permita qualquer requisição apenas porque contém um cabeçalho chamado Signature: a presença do cabeçalho não comprova sua validade.
Verificar o conteúdo assinado
A especificação de segurança do Mastodon descreve a autenticação por assinaturas HTTP. O esquema utilizado, os componentes assinados e as verificações precisam corresponder às versões envolvidas. Verifique o ator, sua chave pública, o relógio e os componentes da solicitação usados na validação.
Revise regras de transformação, reescritas de host ou caminho e alterações no corpo. A referência de cabeçalhos HTTP da Cloudflare ajuda a distinguir o que o proxy acrescenta ou altera. Não afirme que converter HTTP/2 em HTTP/1.1 remove automaticamente Digest ou Signature: uma falha concreta exige evidência nos registros e na configuração.
Separar TLS de assinatura HTTP
TLS protege a conexão; uma assinatura HTTP autentica componentes da mensagem. Ajustar o modo de criptografia não garante que uma reescrita de caminho preserve uma assinatura. Da mesma forma, forçar uma versão TLS não corrige uma chave pública incorreta ou uma atividade rejeitada pelo relay.
Verifique se o certificado da origem é válido para a configuração utilizada e se a conexão pode ser estabelecida com segurança. Não desative a validação do certificado para esconder um erro. Em seguida, examine a verificação de assinatura separadamente.
Confirmar a recuperação
Faça o teste com uma entrega legítima de uma instância de teste autorizada ou observe uma atividade esperada. Uma requisição curl sem corpo ActivityPub válido e sem assinatura pode ser rejeitada corretamente; isso não demonstra defeito no relay.
Confirme o recebimento e o encaminhamento nos registros apropriados. Não presuma um painel de administração idêntico para todos os softwares de relay. Ao solicitar ajuda, compartilhe versões, horários e registros depurados, preservando chaves privadas, credenciais e dados que não sejam necessários ao diagnóstico.