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.

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 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 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é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 primário é desativado e reiniciado como um secundário que não aceita mais conexões dos certificados X.509 antigos.

Saiba mais

Voltar

Atualizar x.509 com novo DN

Use x.509 Extension Values