Rotacione certificados X.509 para usar valores de extensão 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 migrar de certificados identificados usando atributos de nome diferenciado para certificados identificados usando valores de extensão 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.

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 MongoDB e a unidade organizacional MongoDB 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=MongoDB, OU=MongoDB 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 identifique certificados Peering usando valores de extensão.

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 .

Inicialmente, os clusters identificam membros usando valores de nome diferenciado. Com os novos certificados, os servidores identificam membros usando o valor de extensão mongodb://example.mongodb.net e ignoram os atributos do certificado.

Atualizar a configuração de associação do cluster TLS

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

Altere a configuração clusterAuthX509 para corresponder ao novo certificado substituindo a configuração attributes pela configuração extensionValue .
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:
       extensionValue:  mongodb://example.mongodb.net
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDBServer }

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 valores de extensão, bem como os nome diferenciado 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 no conjunto de réplicas é desativado e reiniciado como um secundário que agora aceita conexões de mesmo nível de membros usando certificados com o novo valor de extensão, bem como os atributos DN antigos.

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:
       extensionValue:  mongodb://example.mongodb.net
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDB 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:
       extensionValue:  mongodb://example.mongodb.net
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

Girar x.509 certificados

Exceção do Localhost