Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / / /

Rotacionar certificados X.509 em clusters autogerenciados

Nesta página

  • Sobre esta tarefa
  • Passos
  • Saiba mais

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.

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.

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.

1

Atualize o arquivo de configuração de cada servidor:

  • Altere a configuração do attributes para usar os valores no novo certificado

  • Configure 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 }
2

Reinicie cada membro do cluster secundário:

  1. Use mongosh para se conectar a cada nó do cluster secundário e, em seguida, use o método db.shutdownServer() para parar o servidor:

    use admin
    db.shutdownServer()
  2. Reinicie o servidor.

  3. Use o método rs.status() para determinar o estado membro:

    rs.status().members
  4. Aguarde o campo stateStr para este membro mostrar um valor de SECONDARY 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.

3

Reinicie o membro principal:

  1. Conecte-se ao primário usando mongosh e, em seguida, use o método rs.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.

  2. Use o método db.shutdownServer() para desligar o servidor:

    use admin
    db.shutdownServer()
  3. 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.

4

Atualize o arquivo de configuração de cada servidor:

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 }
5

Reinicie cada membro do cluster secundário:

  1. Use mongosh para se conectar a cada nó do cluster secundário e, em seguida, use o método db.shutdownServer() para parar o servidor:

    use admin
    db.shutdownServer()
  2. Reinicie o servidor.

  3. Use o método rs.status() para determinar o estado membro:

    rs.status().members
  4. Aguarde o campo stateStr para este membro mostrar um valor de SECONDARY 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.

6

Reinicie o membro principal:

  1. Conecte-se ao primário usando mongosh e, em seguida, use o método rs.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.

  2. Use o método db.shutdownServer() para desligar o servidor:

    use admin
    db.shutdownServer()
  3. Reinicie o servidor.

O servidor primário na réplicas é desativado e reiniciado como um secundário que usa o novo certificado X.509.

7

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.

8

Reinicie cada membro do cluster secundário:

  1. Use mongosh para se conectar a cada nó do cluster secundário e, em seguida, use o método db.shutdownServer() para parar o servidor:

    use admin
    db.shutdownServer()
  2. Reinicie o servidor.

  3. Use o método rs.status() para determinar o estado membro:

    rs.status().members
  4. Aguarde o campo stateStr para este membro mostrar um valor de SECONDARY 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.

9

Reinicie o membro principal:

  1. Conecte-se ao primário usando mongosh e, em seguida, use o método rs.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.

  2. Use o método db.shutdownServer() para desligar o servidor:

    use admin
    db.shutdownServer()
  3. 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.

Voltar

Atualizar x.509 com novo DN