Gerenciamento dos certificados

Importante:

The installation process generates self-signed certificates on your behalf. These certificates will expire in 90 days, and you must replace them with certificates signed by a trusted Certificate Authority (CA) as soon as installation completes. If you do not update the certificates, the installation will stop working in 90 days.

O pacote de instalação fornece uma ferramenta de gerenciamento de cluster que permite atualizar certificados após a instalação. Para acessar a ferramenta, navegue até o local do pacote do instalador:

cd /opt/UiPathAutomationSuite/

Gerando uma solicitação de assinatura de certificado (CSR) e uma chave privada

Para gerar o CSR e a chave privada, execute o seguinte comando:

# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf

# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF

# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr

Sua equipe de TI usa os valores obtidos para gerar um certificado assinado. A chave privada gerada permanece local.

Gerenciamento de certificados do servidor

Para visualizar mais informações sobre certificados de servidor, execute o seguinte comando:

sudo ./configureUiPathAS.sh tls-cert --help

Saída:

************************************************************************************

Manage cluster tls and server certificate

Usage:
  configureUiPathAS.sh tls-cert [command]
  configureUiPathAS.sh tls-cert [flags]

Available Commands:
  update                              Update the tls / server certificate

  get                                 Get the tls / server certificate

Flags:
  -h|--help                           Display help

************************************************************************************

As seguintes seções descrevem as operações que você pode realizar usando o comando ./configureUiPathAS.sh tls-cert .

Atualização do certificado do servidor

Instalação online: como encontrar o certificado do servidor

Os certificados são armazenados como um segredo ao nível do Istio. Você pode encontrar certificados sob o nome istio-ingressgateway-certs no namespace istio-system.

Consulte os arquivos de certificado na lista a seguir:

• O certificado do servidor TLS é armazenado como tls.crt
• A chave privada TLS do servidor como tls.key
• O pacote do CA é armazenado como ca.crt

Você pode verificar os segredos usando o seguinte comando:

kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml

Certificates are also stored in the UiPath namespace. This is applicable to every UiPath product that needs certificate information to trust incoming calls. For details, see Understanding the container architecture related to certificates.

Instalação offline: como encontrar o certificado do servidor

In addition to the certificates required by online deployment, an offline deployment has two additional locations that use the same rootCA.crt and tls.crt: ArgoCD and Docker Registry. Certificates are then stored in both Docker and ArgoCD namespaces.

Você pode verificar os segredos usando o seguinte comando:

# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https

Como atualizar os certificados do servidor

Importante:

Você deve descriptografar a chave de certificado antes de atualizar o certificado do servidor. Ignorar a etapa de descriptografia resulta em um erro.

Para descriptografar a chave de certificado, execute o seguinte comando:

# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key

openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key

Execute o script configureUiPathAS.sh para atualizar o certificado conforme mostrado abaixo. Você precisa do caminho para cada um dos três arquivos de certificado. Todo o arquivo de certificado deve estar no formato PEM.

• Pacote de Autoridade de Certificação - Este pacote deve conter apenas os certificados de cadeia usados para assinar o certificado do servidor TLS. O limite da cadeia é de até nove certificados.

• Certificado do Servidor - Certificado de servidor público

• Chave privada - Chave privada para o certificado de servidor

  sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
  

Os arquivos abaixo serão armazenados no /directory/path/to/store/certificatelocal .

Acessando o certificado TLS

Para imprimir os arquivos de certificado, execute o seguinte comando, especificando o diretório em que os certificados são armazenados.

sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate

Adding the CA certificate to the host trust store

Você é o responsável por garantir que os certificados gerados sejam confiáveis.

Para adicionar o certificado ao armazenamento de confiança da VM do host, execute os seguintes comandos em todos os nós no cluster:

# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/

# 2. Update the trust store configuration
update-ca-trust

Gerenciamento de certificados de CA adicionais

Para exibir mais informações sobre certificados de CA adicionais, execute o seguinte comando:

./configureUiPathAS.sh additional-ca-certs --help

Saída:

***************************************************************************************

Manage additional CA certificates, this can be used to add sql server CA

Usage:
  configureUiPathAS.sh additional-ca-certs [command]
  configureUiPathAS.sh additional-ca-certs [flags]

Available Commands:
  update                              Update the additional trusted CA certificates.

  get                                 Get the additional trusted CA certificates

Flags:
  -h|--help                           Display help

***************************************************************************************

As seguintes seções descrevem as operações que você pode realizar usando o comando ./configureUiPathAS.sh additional-ca-certs .

Atualização dos certificados de CA

Este comando ajuda você a atualizar ou substituir os certificados de CA configurados existentes.

./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs

Observação:

O comando acima adiciona um novo certificado à lista de certificados existentes. Se você quiser substituir todos os certificados configurados anteriormente, certifique-se de anexar --replace na etapa final.

O arquivo de pacote do Certificado de CA deve ter um formato .pem válido e pode ter mais de um certificado presente nele.

Acessando os certificados de CA

Para baixar os certificados de CA já configurados, execute o seguinte comando:

./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs

Adding the CA certificate to the host trust store

Você é o responsável por garantir que os certificados gerados sejam confiáveis.

Para adicionar o certificado ao armazenamento de confiança da VM do host, execute os seguintes comandos em todos os nós no cluster:

# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/

# 2. Update the trust store configuration
update-ca-trust

Gerenciando certificados de assinatura de token de identidade

Para visualizar mais informações sobre certificados de assinatura de token de identidade, execute o seguinte comando:

sudo ./configureUiPathAS.sh identity token-cert --help

Saída:

************************************************************************************

Manage Identity token signing certificate

Usage:
  configureUiPathAS.sh identity token-cert [command]
  configureUiPathAS.sh identity token-cert [flags]

Available Commands:
  update                              Update secondary certificate to signing
                                        the authentication token
  rotate                              Switch secondary certificate as a primary
                                        token signing certificate
  get                                 Get token signing certificate

Flags:
  -h|--help                           Display help

************************************************************************************

A seção a seguir fornece detalhes sobre as operações que você pode realizar usando o comando./configureUiPathAS.sh identity token-cert .

Atualização do certificado

O comando a seguir carrega o novo certificado para assinar o token. Observe que ele não substitui o certificado de assinatura existente do token. O certificado deve estar no formato pkcs12 com a extensão .pfx.

Observação:

Make sure the value you provide for the --password flag is between simple quotation marks. For example: --password 'CertificatePassword!@#'.

sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --password '<cert_pass>'

Rotacionando o certificado

Isso irá rotacionar ou trocar o certificado antigo pelo novo carregado usando a atualização de certificado.

sudo ./configureUiPathAS.sh identity token-cert rotate

Observação:

Deve haver um prazo de entrega de cerca de 24 a 48 horas entre a atualização e a rotação do certificado.

Precisamos desse prazo de entrega para continuar dando suporte à autenticação do token em cache assinado pelo certificado antigo.

Se você rotar o certificado muito antes da expiração do token de cache, poderá resultar em tempo de inatividade. E você pode ter que reiniciar todos os seus robôs.

Rotação emergencial de certificado

Importante:

O procedimento a seguir é apenas para emergências. Você deve rotacionar os certificados antes de suas datas de expiração

Para realizar uma atualização emergencial de certificado, execute as seguintes etapas:

1. Obtenha um novo certificado ou crie um autoassinado e copie-o para o nó do servidor de cluster usado para executar as próximas etapas de rotação. Para criar um novo certificado autoassinado, execute o comando a seguir:

   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout identityserver.key -out identityserver.crt
   openssl pkcs12 -export -out identityserver.pfx -inkey identityserver.key -in identityserver.crt
   

2. If IdentityServer1.pfx is expired, rotate and update the certificate. For instructions, see Rotating the certificate.

3. Se o IdentityServer2.pfx estiver expirado, atualize o certificado.

4. Se ambos os certificados expiraram, atualize, rotacione e atualize novamente.

5. Restart all deployments. For instructions, see Troubleshooting.

6. Limpe todos os caches do navegador. Se você executar no modo de navegação anônima ou privada, poderá pular esta etapa.

   1. For Firefox, press CTRL+SHIFT+DEL, select Cache, and click OK.

      

   2. For Chrome, press CTRL+SHIFT+DEL, select Cached images and files, and click Clear data.

      

Acessando o certificado

Execute o seguinte comando para baixar o certificado de assinatura de token atual:

sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate

Gerenciamento de certificados do RKE2

Por padrão, os certificados do RKE2 expiram em 12 meses. Nos 90 dias antes da data de expiração, os certificados são girados quando você reinicializa o RKE2.

Para obter mais detalhes, consulte RKE2 - Opções avançadas - Rotação do certificado.

Verificação da data de expiração do certificado do RKE2

Para verificar a data de expiração do certificado do RKE2, execute o seguinte comando em qualquer um dos nós:

if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
  dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
  dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done

A saída que você obtém deve ser semelhante à mostrada na imagem a seguir:

Rotação do certificado RKE2

Por padrão, os certificados do RKE2 expiram em 12 meses. Nos 90 dias antes da data de expiração, os certificados são girados quando você reinicializa o RKE2. No entanto, se a validade dos certificados exceder o período de 90 dias, você deve rotacionar manualmente os certificados seguindo as etapas mencionadas no RKE2 - Opções avançadas - Rotação de certificados.

Se você quiser personalizar o período de expiração dos certificados do RKE2 para atender a requisitos específicos, poderá fazê-lo antes de reiniciar os serviços do RKE2 para nós de servidor e de agente.

Para girar os certificados do RKE2, você deve primeiro executar uma série de ações nos nós do servidor e, em seguida, prosseguir com algumas etapas nos nós do agente.

Execute as seguintes etapas nos nós do servidor:

1. Pare o servidor RKE2:

   systemctl stop rke2-server.service
   

2. Limpe quaisquer processos do RKE2 restantes:

   rke2-killall.sh
   

3. Exclua o arquivo dynamic-cert.json localizado em /var/lib/rancher/rke2/server/tls/.

4. Para personalizar o período de expiração dos certificados do RKE2, use o seguinte comando. Esteja ciente de que esse exemplo define o período de validade para 1000 dias, mas você pode alterar esse valor com base em seus requisitos.

   SERVICE_NAME="rke2-server.service"
   conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf"
   mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/
   
   cat > "$conf_file_path" <<EOF
   [Service]
   Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000"
   EOF
   
   systemctl daemon-reload
   

5. Reinicie o servidor RKE2:

   systemctl start rke2-server.service
   

   Observação:

   Se o cluster tiver mais de um nó do servidor, as etapas 1-4 podem não ser executadas totalmente, pois etcd pode não ser capaz de concluir a eleição do líder. Se isso acontecer, repita as etapas 1-4 em outros nós do servidor.

6. Exclua o segredo rke2-serving do namespace kube-system:

   kubectl delete secret -n kube-system rke2-serving
   

   Observação:

   Em uma implantação de vários nós, você pode não ser capaz de executar os comandos kubectl antes de concluir as quatro primeiras operações no número necessário de nós do servidor. Isso é para atender ao requisito do quorum etcd. Você pode remover o segredo rke2-serving imediatamente após o início do servidor RKE2.

Depois que o etcd atingir o quorum, o servidor RKE2 pode iniciar o resto dos pods do plano de controle. Você deve então ver a execução bem-sucedida do comando kubectl get nodes. Quando os nós do seu servidor estiverem prontos, você pode prosseguir para os nós do agente para regenerar os certificados.

Execute as seguintes etapas nos nós do agente:

1. Pare o servidor RKE2:

   systemctl stop rke2-agent.service
   

2. Limpe quaisquer processos do RKE2 restantes:

   rke2-killall.sh
   

3. Para personalizar o período de expiração dos certificados do RKE2, use o seguinte comando. Esteja ciente de que esse exemplo define o período de validade para 1000 dias, mas você pode alterar esse valor com base em seus requisitos.

   SERVICE_NAME="rke2-agent.service"
   conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf"
   mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/
   
   cat > "$conf_file_path" <<EOF
   [Service]
   Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000"
   EOF
   
   systemctl daemon-reload
   

4. Reinicie o servidor RKE2:

   systemctl start rke2-agent.service