Gerenciamento dos certificados

Importante:

O processo de instalação gera certificados autoassinados em seu nome. Esses certificados são compatíveis com FIPS e expirarão em 90 dias. Você deve substituí-los por certificados assinados por uma Autoridade de Certificação (CA) confiável assim que a instalação for concluída.

Se você não atualizar os certificados, a instalação deixará de funcionar após 90 dias. Se você instalou o Automation Suite em um host habilitado para FIPS e deseja atualizar os certificados, verifique se são compatíveis com FIPS.

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/

Generating a Certificate Signing Request (CSR) and a private key

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

Os certificados também são armazenados no namespace da UiPath. Isso é aplicável a todos os produtos UiPath® que precisam de informações de certificado para confiar nas solicitações recebidas. Para detalhes, consulte Entendendo a arquitetura do contêiner relacionada a certificados.

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

Além dos certificados exigidos pela implantação online, uma implantação offline tem dois locais adicionais que usam o mesmo rootCA.crt e tls.crt: ArgoCD e Docker Registry. Os certificados são armazenados nos namespaces do Docker e do ArgoCD.

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.

Essa etapa é necessária quando seu ambiente usa uma CA privada ou um certificado autoassinado que não é globalmente confiável. Se a CA privada já não estiver presente no armazenamento de confiança do host Linux, as chamadas originadas dos nós do host falharão com erros de SSL. Se seu CA já for confiável pelo host, você poderá pular essa etapa.

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.

Use esse comando quando seu ambiente depender de uma CA privada ou certificado autoassinado. Adicionar o certificado da CA permite que os serviços do Automation Suite se comuniquem de forma segura com componentes externos que usam certificados assinados por essa CA, como o SQL Server, objectstore ou servidores SMTP.

./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.

Essa etapa é necessária quando seu ambiente usa uma CA privada ou um certificado autoassinado que não é globalmente confiável. Se a CA privada já não estiver presente no armazenamento de confiança do host Linux, as chamadas originadas dos nós do host falharão com erros de SSL. Se seu CA já for confiável pelo host, você poderá pular essa etapa.

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

Para ambientes Windows, consulte este guia para instalar certificados raiz confiáveis.

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

Para fazer upload do novo certificado para assinar o token, execute o seguinte comando:

Observação:

O comando a seguir não substitui o certificado de assinatura de token existente.

Certifique-se de que o certificado fornecido esteja no formato .pem .

sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey

Rotacionando o certificado

Para rotacionar ou substituir o certificado antigo pelo novo, execute o seguinte comando:

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. Se IdentityServer1.pfx estiver expirado, rotacione e atualize o certificado. Para instruções, consulte Rotacionando o certificado.

3. Se IdentityServer2.pfx expirou, atualize o certificado.

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

5. Reinicie todas as implantações. Para obter instruções, consulte Solução de problemas.

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

7. No Firefox, pressione CTRL+SHIFT+DEL, selecione Cache e selecione OK.

   

8. No Chrome, pressione CTRL+SHIFT+DEL, selecione Imagens e arquivos em cache e selecione Limpar dados.

   

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
   

Gerenciamento do certificado de registro externo compatível com OCI

Para atualizar o certificado para o registro externo compatível com OCI após a instalação, adote as seguintes etapas:

1. Atualize o sinalizador registry_ca_cert no arquivo cluster_config.json . Para obter detalhes, consulte Configuração do registro externo compatível com OCI.
2. Atualize a CA raiz usada pelo registro externo compatível com OCI executando o seguinte comando em todos os nós:

   ./bin/uipathctl rke2 generate-registries cluster_config.json --current-config-path /etc/rancher/rke2/registries.yaml > /etc/rancher/rke2/registries.yaml.tmp
   mv -f /etc/rancher/rke2/registries.yaml.tmp /etc/rancher/rke2/registries.yaml
   systemctl restart rke2-server || systemctl restart rke2-agent
   

3. Atualize o certificado de CA confiável do ArgoCD para o registro externo compatível com OCI:

   ./bin/uipathctl config argocd ca-certificates update --cacert [PATH]