Rotação de Chave Pública de Federação no Mastodon: Como Rotacionar Sem Quebras

Sua instância Mastodon usa chaves públicas criptográficas para assinar cada mensagem enviada a outros servidores no fediverso. Quando essas chaves expiram ou vazam, é necessário rotacioná-las para manter a federação segura. No entanto, rotacionar uma chave pública incorretamente pode quebrar a comunicação com milhares de instâncias remotas, fazendo com que postagens, impulsionamentos e seguidores falhem silenciosamente. Este artigo explica por que a rotação de chaves causa interrupções na federação e fornece um método passo a passo para rotacionar as chaves públicas do Mastodon sem perder a conectividade.

Por que Rotacionar uma Chave Pública do Mastodon Quebra a Federação

Cada conta do Mastodon tem um par de chaves RSA pública-privada armazenado no banco de dados. Quando sua instância envia uma atividade para um servidor remoto, ela assina a requisição HTTP com a chave privada. O servidor remoto consulta a chave pública do objeto Actor da sua conta (recuperado via ActivityPub) e verifica a assinatura. Se você rotacionar a chave em sua instância, mas o servidor remoto ainda tiver a chave pública antiga, todas as requisições assinadas futuras falharão na verificação. O servidor remoto rejeita a atividade, e suas postagens, impulsionamentos e seguidores nunca aparecem nesse servidor. Esse estado persiste até que o servidor remoto busque seu objeto Actor atualizado, que contém a nova chave pública. O atraso pode durar horas porque os servidores remotos armazenam objetos Actor em cache de forma agressiva para reduzir a carga.

O Mastodon não transmite alterações de chave automaticamente. O protocolo não possui uma mensagem padrão para dizer “minha chave mudou”. Em vez disso, o servidor remoto precisa buscar novamente seu objeto Actor. A nova busca ocorre apenas quando o servidor remoto recebe uma atividade sua e a verificação de assinatura em cache falha. Isso cria um ciclo vicioso: o servidor remoto não consegue verificar a assinatura, então rejeita a atividade e, portanto, nunca aprende a nova chave. A solução é forçar o servidor remoto a buscar novamente seu objeto Actor antes ou imediatamente após a rotação da chave.

O que Acontece com Itens Assinados Existentes Após a Rotação

Atividades já entregues e aceitas por servidores remotos permanecem válidas. O servidor remoto armazena o conteúdo da atividade, não a assinatura. A rotação de chave afeta apenas entregas futuras. Postagens, impulsionamentos e seguidores antigos que já foram aceitos permanecem visíveis nas instâncias remotas. No entanto, quaisquer entregas pendentes em sua fila do Sidekiq que foram assinadas com a chave antiga falharão após a rotação. Esses jobs devem ser repetidos depois que os servidores remotos tiverem a nova chave.

Passos para Rotacionar Chaves de Federação do Mastodon Sem Quebras

O método a seguir rotaciona a chave pública de uma única conta enquanto minimiza o tempo de inatividade da federação. Execute estas etapas durante uma janela de manutenção com baixo tráfego.

1. Faça backup do par de chaves atual
   Acesse seu servidor Mastodon via SSH. Navegue até o diretório do Mastodon. Execute cd /home/mastodon/live e depois RAILS_ENV=production bin/tootctl accounts rotate [nome_de_usuario]. Este comando rotaciona a chave usando a ferramenta integrada do Mastodon. Ele também envia um sinal de nova busca forçada para servidores remotos que interagiram recentemente com a conta. Este é o método mais seguro porque atualiza o objeto Actor imediatamente.
2. Verifique a atualização da chave no objeto Actor local
   Abra um Rails console: RAILS_ENV=production bin/rails c. Execute a = Account.find_local('nome_de_usuario'); puts a.public_key. Confirme que a string da chave é diferente do backup que você salvou anteriormente. Isso verifica se a rotação foi bem-sucedida.
3. Limpe a fila local do Sidekiq para entregas de federação
   Servidores remotos que já falharam ao entregar uma atividade podem ter a chave antiga em cache. Reinicie o Sidekiq para limpar o cache em memória: systemctl restart sidekiq. Isso força o Sidekiq a recarregar a chave pública da conta do banco de dados antes de repetir quaisquer entregas com falha.
4. Force uma nova busca dos servidores remotos
   Envie uma atividade fictícia para algumas instâncias remotas importantes para acionar uma nova busca. Use a interface web do Mastodon para publicar um toot público mencionando @admin@instanciaremota.social. O servidor remoto tentará verificar a assinatura, falhará, buscará o objeto Actor atualizado e armazenará a nova chave em cache. Após isso, todas as entregas subsequentes serão bem-sucedidas.
5. Monitore os logs de federação em busca de falhas de assinatura
   Verifique os logs do Mastodon: journalctl -u mastodon-web -f | grep "signature". Procure por linhas contendo “signature verification failed”. Se você vir falhas mais de 10 minutos após o passo 4, o servidor remoto pode não ter feito a nova busca. Repita o passo 4 com uma instância remota diferente.
6. Verifique a rotação da chave em uma instância remota
   Use um cliente Mastodon em um servidor diferente. Abra a página de perfil da conta rotacionada. A URL da chave pública está em https://suainstancia.social/users/nome_de_usuario#main-key. Um administrador remoto pode buscar esta URL diretamente para ver a nova chave. Se a chave corresponder ao que você vê no Rails console, a rotação está visível para o fediverso.

Método Alternativo: Atualização Manual de Chave via Rails Console

Se o comando integrado tootctl não estiver disponível ou você precisar rotacionar apenas a chave pública sem alterar a chave privada, use o Rails console diretamente. Este método é mais arriscado porque não aciona o sinal de nova busca forçada. Use-o apenas se você entender as consequências.

1. Gere um novo par de chaves RSA
   No Rails console, execute new_key = OpenSSL::PKey::RSA.new(2048). Isso cria uma nova chave privada. A chave pública é derivada dela.
2. Atualize o registro da conta
   Execute Account.find_local('nome_de_usuario').update!(public_key: new_key.public_key). Isso sobrescreve a chave pública no banco de dados. A chave privada permanece inalterada no banco de dados, então você também deve atualizá-la: Account.find_local('nome_de_usuario').update!(private_key: new_key.to_pem). Se você alterar apenas a chave pública, a geração de assinatura falhará porque a chave privada não corresponderá mais.
3. Reinicie o Mastodon web e o Sidekiq
   Execute systemctl restart mastodon-web sidekiq. Isso força o aplicativo a recarregar as chaves da conta do banco de dados.
4. Force a nova busca manualmente
   Como o método manual não envia um sinal de nova busca, você deve confiar na primeira atividade que chegar a um servidor remoto. Publique um toot público imediatamente. Monitore os logs em busca de falhas de assinatura conforme descrito no passo 5 do método principal.

Se o Mastodon Ainda Tiver Problemas de Federação Após a Rotação de Chave

Servidores Remotos Ainda Rejeitam Atividades Após 24 Horas

Algumas instâncias remotas armazenam objetos Actor em cache por até 48 horas. Se você rotacionou a chave e os servidores remotos ainda rejeitam atividades após 24 horas, o servidor remoto pode ter um bug em sua lógica de cache. Entre em contato com o administrador da instância remota e peça para limpar manualmente o cache do objeto Actor da sua conta. Alternativamente, publique um toot público que inclua um link para a URL do objeto Actor da sua conta. Alguns servidores farão uma nova busca quando virem a URL em um toot.

Acúmulo na Fila do Sidekiq Após a Rotação

Após a rotação, o Sidekiq pode ter milhares de jobs de entrega com falha na fila de repetição. Esses jobs foram assinados com a chave antiga. Eles continuarão falhando até que o servidor remoto busque sua chave novamente. Para acelerar a recuperação, limpe a fila de repetição e deixe o sistema recriar os jobs: RAILS_ENV=production bin/tootctl sidekiq clear. Isso remove todos os jobs pendentes, incluindo repetições. Novas atividades serão criadas e entregues com a nova chave. Isso é seguro porque o Mastodon regenera atividades perdidas do banco de dados quando necessário.

A Roração de Chave Não Entra em Efeito para Algumas Contas

Se você rotacionou a chave para uma conta, mas outras contas na mesma instância não foram afetadas, o problema está isolado nessa conta. Verifique se a chave pública da conta no banco de dados é única. O Mastodon armazena o par de chaves de cada conta separadamente. Se a atualização do banco de dados falhou silenciosamente, execute o comando de rotação novamente e confirme se a chave mudou usando o método do Rails console descrito no passo 2 do método principal.

Item	Rotação Integrada com tootctl	Rotação Manual via Rails Console
Descrição	Usa a ferramenta oficial de rotação de chaves do Mastodon	Atualiza diretamente os campos do banco de dados via Rails console
Sinal de nova busca forçada enviado	Sim	Não
Risco de quebra na federação	Baixo	Alto
Requer acesso ao servidor	SSH e tootctl	SSH e Rails console
Melhor caso de uso	Rotação de chave rotineira	Alteração de chave de emergência quando tootctl está quebrado

Agora você pode rotacionar as chaves públicas de federação da sua instância Mastodon com o mínimo de interrupção usando o comando integrado tootctl e forçando uma nova busca dos servidores remotos. Para rotações rotineiras, agende-as durante horários de baixo tráfego e monitore os logs de federação por 30 minutos depois. Como dica avançada, configure um alerta de monitoramento para o padrão de log signature verification failed para detectar problemas relacionados a chaves antes que os usuários os relatem.