Como rotacionar certificados X.509 no Percona Server for MongoDB sem parar o serviço

Certificado TLS expirado é um dos incidentes mais previsíveis e, ainda assim, dos mais dolorosos em produção. Quando o X.509 vale só para conexões de cliente, o vencimento derruba a entrada de novas sessões. Quando ele também é usado para autenticação interna entre os nós de um replica set ou de um cluster sharded, o problema é mais grave: os próprios membros deixam de se autenticar uns com os outros. É esse cenário que um artigo recente de Ivan Groenewold, no blog da Percona, endereça, mostrando como renovar os certificados com interrupção mínima usando o comando rotateCertificates.

O ponto central do texto é uma distinção que o DBA precisa ter clara antes de tocar em qualquer arquivo: existe a renovação simples (mesma CA) e existe a troca estrutural (CA nova, DN diferente, atributos de associação de cluster alterados). Só a primeira é elegível para o recarregamento a quente. Confundir as duas é o caminho mais curto para um cluster quebrado.

O que é uma renovação com a mesma CA

O procedimento descrito é o que a Percona chama de same-CA renewal: os certificados de servidor, de membro e de cliente são reemitidos pela mesma CA já confiável, e os atributos X.509 usados para a associação ao cluster não mudam. Na prática, isso significa que a cadeia de confiança permanece idêntica e os valores de O (Organization), OU (Organizational Unit) e DC (Domain Component) usados no matching de associação interna continuam os mesmos.

Se nada disso muda, o mongod e o mongos conseguem simplesmente reler os arquivos de certificado e passar a apresentá-los em novas conexões, sem reinício de processo e sem eleição forçada no replica set. É aí que mora o ganho operacional.

Do not apply this hot-reload procedure when replacing the issuing CA, changing a certificate subject DN, or changing cluster-membership attributes. Those are not ordinary renewals.

Ivan Groenewold, Percona

O que é recarregado e o que não é

O Percona Server for MongoDB↳MongoDB19 conteúdosMongoDB e LGPD: Quais os recursos disponíveis?Data · jul 2019Laravel & MongoDB: saiba mais sobre embedded documentsData · abr 2021LEFT JOIN no MongoDB, não é magia… É Aggregation Framework!!!Data · set 2019Ver tudo em Data → relê os arquivos apontados por três diretivas de configuração TLS:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongod/tls/server.pem
    CAFile: /etc/mongod/tls/ca.pem
    clusterFile: /etc/mongod/tls/cluster.pem

O certificateKeyFile guarda o certificado e a chave privada apresentados aos clientes comuns. O clusterFile guarda o certificado e a chave que um processo mongod ou mongos apresenta ao se conectar aos outros membros do cluster. Detalhe que evita dor de cabeça: se o clusterFile não estiver configurado, o certificateKeyFile também é usado para a autenticação entre membros, ou seja, um único arquivo carrega os dois papéis.

O comportamento do rotateCertificates é deliberadamente conservador. Ele afeta apenas novas conexões TLS. Sessões de cliente já estabelecidas não são encerradas, e o comando não dispara eleição no replica set. Essa é justamente a propriedade que torna a operação compatível com a exigência de zero downtime tão comum em ambientes regulados no Brasil, onde parar o serviço para trocar um certificado é, muitas vezes, inaceitável.

Preparação antes da janela de manutenção

A recomendação da fonte é começar bem antes do vencimento e nunca fazer a primeira tentativa em produção. O roteiro de preparação envolve alguns cuidados que valem repetir:

• Inventariar todos os processos e certificados de cliente. Isso inclui cada membro mongod, cada roteador mongos, os drivers das aplicações, os hosts com mongosh, os jobs de backup, o monitoramento e as ferramentas de automação. Um certificado de cliente esquecido em um job de backup vira incidente às três da manhã.
• Confirmar que é uma renovação com a mesma CA. A cadeia do emissor confiável precisa permanecer igual, e os atributos O, OU e DC do matching interno não podem mudar.
• Montar um novo arquivo PEM para cada servidor e cliente. O arquivo referenciado por certificateKeyFile ou clusterFile precisa conter tanto o certificado quanto a chave privada correspondente, e nesta ordem: a chave primeiro, seguida do certificado, com os delimitadores de encapsulamento preservados.
• Validar o certificado contra a CA e conferir os detalhes antes de copiar qualquer coisa para o diretório TLS de produção.

Restrições do recarregamento online

Há duas limitações que precisam ser respeitadas ao rotacionar a quente:

Se CAFile, uma CRL ou qualquer outra entrada TLS configurada também estiver sendo renovada na mesma operação, é preciso substituí-la antes de invocar o recarregamento. O comando relê as entradas TLS como um conjunto: uma entrada ausente ou inválida faz o recarregamento falhar por inteiro.

Aqui vale um ponto de tranquilidade destacado na fonte: arquivos de certificado incorretos fazem a rotação falhar, mas não invalidam a configuração existente nem produzem efeitos colaterais. O processo continua servindo com o material anterior. Do ponto de vista de quem opera, isso transforma o rotateCertificates em uma operação com falha segura, o que reduz bastante o risco da janela.

Executando a rotação

A execução em si é direta. Conecte-se diretamente ao mongod ou mongos específico com um usuário administrativo e rode:

db.getSiblingDB("admin").runCommand({rotateCertificates: 1, message: "Renewed TLS certificate"})

O campo message é registrado no log e serve de trilha de auditoria da operação, algo que ajuda em ambientes de compliance. Logo após executar, o próprio autor recomenda validar imediatamente uma nova conexão TLS àquele processo usando um certificado de cliente renovado, além de inspecionar o log em busca da mensagem de rotação bem-sucedida e de eventuais erros de TLS. Para replica sets e clusters sharded, a Percona aponta a documentação com o passo a passo específico, já que a ordem de aplicação entre membros importa.

Validação final e limpeza

Depois de concluir, o roteiro sugere reconferir a data de expiração e os SANs do certificado apresentado por cada mongod e mongos. Os certificados antigos só devem ser mantidos durante o período de sobreposição aprovado, e depois removidos ou revogados. E, fechando o ciclo de operação madura: registrar as novas datas de expiração e criar alertas com antecedência suficiente. Rotação de certificado que não gera um alerta para a próxima rotação é uma dívida técnica que só se cobra no vencimento.

Quando este procedimento NÃO vale

A fronteira é explícita. O recarregamento a quente não se aplica quando muda qualquer um dos itens abaixo:

• a CA emissora ou a cadeia de CA confiável;
• o subject DN usado por um usuário cliente MONGODB-X509;
• os valores de O, OU ou DC usados no matching padrão de associação intra-cluster;
• net.tls.clusterAuthX509.attributes ou net.tls.clusterAuthX509.extensionValue.

Nesses casos, a identidade do membro ou a raiz de confiança está mudando, e um simples reload não dá conta, exige um procedimento próprio de convivência entre CAs, que a fonte deixa para um artigo futuro. Para o DBA, a mensagem prática é clara: antes de agendar a janela, classifique corretamente o tipo de renovação. Tratar uma troca de CA como se fosse renovação de rotina é o erro que transforma uma tarefa de cinco minutos em um incidente de indisponibilidade do cluster inteiro.

Fonte: Percona Database Blog