Rotacione x.509 certificados com clusterAuthX509 atributos em clusters autogerenciados

Nesta página

Sobre esta tarefa

Passos
Saiba mais

Novidades na versão 7.0.

Os membros do cluster podem usar certificados x.509 para autenticação de associação para identificar outros servidores na mesma implantação. Este tutorial descreve como executar uma atualização contínua para girar509 certificados x. em um cluster que usa as net.tls.clusterAuthX509.attributes configurações para configurar os atributos de Nome Distinto (DN) dos membros do cluster.

Observação

Para executar uma atualização contínua para girar certificados em um cluster que não use as configurações e não o fará após a atualização,net.tls.clusterAuthX509 consulte Girar x.509 Certificados sem clusterAuthX509 Atributos em Clusters Autogerenciados.

Quando um servidor configurado com a configuração recebe uma solicitação de conexão, ele compara os atributos de Nome Distinto (DN)net.tls.clusterAuthX509.attributes no subject campo dos certificados apresentados com os valores configurados da configuração attributes e tlsClusterAuthX509Override do parâmetro. Se os valores corresponderem, ele tratará a conexão como um membro do cluster.

Em algumas situações, talvez seja necessário atualizar os certificados de membros para novos certificados com um novo Nome Distinto (DN), como se uma organização alterasse seu nome. Em uma atualização contínua, os certificados de membro são atualizados um de cada vez e seu sistema não incorre em nenhum tempo de inatividade.

Os clusters que adotam novos certificados podem usar o parâmetro para aceitar tlsClusterAuthX509Override x.509 certificados com diferentes atributos DN de assunto durante o procedimento de rotação de certificados. Quando todos os membros usarem certificados com o novo valor, remova a substituição para começar a rejeitar os certificados agora desatualizados.

Sobre esta tarefa

Considere um conjunto de réplicas em que os certificados de membro, definidos usando as configurações e, têm atributos de DN (Distinguished Name) que usam clusterFile certificateKeyFile a 10gen organização e a 10gen Server unidade organizacional. Estes atributos DN são definidos usando a net.tls.clusterAuthX509.attributes configuração.

Um membro deste conjunto de réplicas possui o seguinte arquivo de configuração:

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

O procedimento a seguir atualiza os certificados x.509 de cada membro do conjunto de réplicas para novos certificados com atributos DN que usam a organização MongoDB e a unidade organizacional MongoDB Server.

Observação

O procedimento a seguir pressupõe que os novos certificados x. atendam509 ao certificado de associação e a todos os outros requisitos e que a configuração do cluster identifica certificados de mesmo nível usando valores de nome distinto (DN). Para obter mais informações, consulte Requisitos de certificado de membro.

Passos

Estas etapas atualizam certificados de membro para utilizar novos509 certificados x. em um cluster configurado com a net.tls.clusterAuthX509.attributes configuração.

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

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étodo db.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 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.

Reiniciar membro do cluster primário

Reinicie o membro principal:

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.
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étodo db.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 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.

Reiniciar membro do cluster primário

Reinicie o membro principal:

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.
Use o método db.shutdownServer() para desligar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.

O servidor primary no conjunto de 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 novo509 certificado x., atualize o arquivo tlsClusterAuthX509Override setParameter de configuração para remover as configurações do parâmetro.

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étodo db.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 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.

Reiniciar membro do cluster primário

Reinicie o membro principal:

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.
Use o método db.shutdownServer() para desligar o servidor:
```
use admin
db.shutdownServer()
```
Reinicie o servidor.

O servidor primary é desativado e reiniciado como um secundário que não aceita mais conexões dos certificados x.509 antigos.

Saiba mais

Voltar

Gire x.509 com Novo DN

Gire x.509 para usar valores de extensão