Rotacionar certificados X.509 em clusters autogerenciados
Nesta página
Novidades na versão 7.0.
Os membros do cluster podem utilizar certificados X.509 paraautenticação de associação do para identificar outros servidores na mesma implantação.
Quando o servidor recebe uma solicitação de conexão, ele compara os valores de Nome Distinto (DN) ou a cadeia de valores de extensão do certificado com os valores configurados da configuração clusterAuthX509
e do parâmetro tlsClusterAuthX509Override
. Se os valores corresponderem, ele tratará a conexão como um membro do cluster.
Os clusters que adotam novos certificados podem usar o parâmetro tlsClusterAuthX509Override
para aceitar certificados X.509 com diferentes atributos de nome diferenciado durante o procedimento de rotação de certificados. Depois que todos os membros usarem certificados com o novo valor, remova a substituição para começar a rejeitar os certificados agora desatualizados.
Observação
Para executar uma atualização contínua para girar certificados em um cluster que não usa as configurações net.tls.clusterAuthX509
e não o fará após a atualização, consulte Atualização contínua de x.509 Certificados que contêm novo DN em clusters autogerenciados.
Sobre esta tarefa
Considere um conjunto de réplicas em que os certificados-membro (definidos usando as configurações clusterFile
e certificateKeyFile
) têm valores de nome diferenciado que usam a organização 10gen
e a unidade organizacional 10gen Server
(definidos usando a configuração attributes
).
security: clusterAuthMode: x509 net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/10gen-server1.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/10gen-cluster1.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=10gen, OU=10gen Server
Este tutorial pressupõe que os novos certificados X.509 atendam ao certificado de associação e a todos os outros requisitos e que a configuração do cluster identifica certificados de Peering usando valores de nome diferenciado (nome diferenciado).
Para obter detalhes, consulte Requisitos de certificado de membro.
Passos
Estas etapas atualizam certificados de membro para utilizar novos certificados X.509 em um cluster configurado com a configuração attributes
.
Os novos certificados têm nome diferenciado (DN) que alteram os atributos da organização (O) de 10gen
para MongoDB
e o atributo Unidade Organizacional (OU) de 10gen Server
para MongoDB Server
.
Atualizar a configuração de associação do cluster TLS
Atualize o arquivo de configuração de cada servidor:
Altere a configuração do
attributes
para usar os valores no novo certificadoConfigure o parâmetro
tlsClusterAuthX509Override
para utilizar os atributos DN do certificado antigo.
Por exemplo:
net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/mongodb-server1.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/mongodb-cluster1.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server security: clusterAuthMode: x509 setParameter: tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }
Reiniciar membros do cluster secundário
Reinicie cada membro do cluster secundário:
Use
mongosh
para se conectar a cada nó do cluster secundário e, em seguida, use o métododb.shutdownServer()
para parar o servidor:use admin db.shutdownServer() Reinicie o servidor.
Use o método
rs.status()
para determinar o estado membro:rs.status().members Aguarde o campo
stateStr
para este membro mostrar um valor deSECONDARY
e, em seguida, reinicie o próximo secundário.
Os servidor secundários no conjunto de réplicas agora aceitam conexões de Peering de membros usando certificados com os novos atributos de nome diferenciado.
Reiniciar membro do cluster primário
Reinicie o membro principal:
Conecte-se ao primário usando
mongosh
e, em seguida, use o métodors.stepDown()
para reduzir o membro como primário:rs.stepDown() O cluster promove um secundário com o novo certificado para servir como o novo primário.
Use o método
db.shutdownServer()
para desligar o servidor:use admin db.shutdownServer() Reinicie o servidor.
O servidor primário no conjunto de réplicas é desativado e reiniciado como um servidor secundário que agora aceita conexões de Peering de membros que usam certificados com os novos atributos de nome diferenciado.
Atualizar os certificados TLS
Atualize o arquivo de configuração de cada servidor:
Altere a configuração
net.tls.certificateKeyFile
para usar o novo certificado.Altere a configuração
net.tls.clusterFile
para usar o novo certificado.
Por exemplo:
net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/mongodb-server2.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/mongodb-cluster2.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server security: clusterAuthMode: x509 setParameter: tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }
Reiniciar membros do cluster secundário
Reinicie cada membro do cluster secundário:
Use
mongosh
para se conectar a cada nó do cluster secundário e, em seguida, use o métododb.shutdownServer()
para parar o servidor:use admin db.shutdownServer() Reinicie o servidor.
Use o método
rs.status()
para determinar o estado membro:rs.status().members Aguarde o campo
stateStr
para este membro mostrar um valor deSECONDARY
e, em seguida, reinicie o próximo secundário.
Os servidores secundários no conjunto de réplicas agora usam os novos certificados X.509.
Reiniciar membro do cluster primário
Reinicie o membro principal:
Conecte-se ao primário usando
mongosh
e, em seguida, use o métodors.stepDown()
para reduzir o membro como primário:rs.stepDown() O cluster promove um secundário com o novo certificado para servir como o novo primário.
Use o método
db.shutdownServer()
para desligar o servidor:use admin db.shutdownServer() Reinicie o servidor.
O servidor primário na réplicas é desativado e reiniciado como um secundário que usa o novo certificado X.509.
Remover a configuração de substituição de certificação nome diferenciado
Com todos os membros do cluster agora usando o novo certificado X.509, atualize o arquivo de configuração para remover as configurações setParameter
do parâmetro tlsClusterAuthX509Override
.
Por exemplo:
net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/mongodb-server1.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/mongodb-cluster1.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server security: clusterAuthMode: x509
Isso garante que o servidor não defina as configurações antigas do certificado na inicialização.
Reiniciar membros do cluster secundário
Reinicie cada membro do cluster secundário:
Use
mongosh
para se conectar a cada nó do cluster secundário e, em seguida, use o métododb.shutdownServer()
para parar o servidor:use admin db.shutdownServer() Reinicie o servidor.
Use o método
rs.status()
para determinar o estado membro:rs.status().members Aguarde o campo
stateStr
para este membro mostrar um valor deSECONDARY
e, em seguida, reinicie o próximo secundário.
Os servidores secundários no conjunto de réplicas são reiniciados e não aceitam mais conexões dos certificados X.509 antigos.
Reiniciar membro do cluster primário
Reinicie o membro principal:
Conecte-se ao primário usando
mongosh
e, em seguida, use o métodors.stepDown()
para reduzir o membro como primário:rs.stepDown() O cluster promove um secundário com o novo certificado para servir como o novo primário.
Use o método
db.shutdownServer()
para desligar o servidor:use admin db.shutdownServer() Reinicie o servidor.
O servidor primário é desativado e reiniciado como um secundário que não aceita mais conexões dos certificados X.509 antigos.