Gerenciamento dos certificados

Substitua certificados autoassinados por certificados assinados por CA e gerencie o ciclo de vida dos certificados no Automation Suite.

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,DNS:apps.$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:

./bin/uipathctl config tls-certificates --help

Saída:

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

Manage tls certificates

Usage:
  uipathctl config tls-certificates [flags]
  uipathctl config tls-certificates [command]

Available Commands:
  get         Get the current tls certificates
  update      Update tls certificates

Flags:
  -h, --help   help for tls-certificates

Global Flags:
      --context string      name of the kubeconfig context to use
  -f, --force               override all user prompts to true
      --kubeconfig string   kubectl configuration file (default: ~/.kube/config)
      --log-format string   log format. one of [text,json] (default "text")
      --log-level string    set log level. one of [trace,debug,info,error] (default "info")
  -q, --quiet                disable progress indicators (emoji/formatted status messages)
      --timeout duration    timeout of the command (default: 90 minutes) (default 1h30m0s)
      --versions string     optional path to versions file

Use "uipathctl config tls-certificates [command] --help" for more information about a command.

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

As seguintes seções descrevem as operações que você pode realizar usando o comando uipathctl config tls-certificates .

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

Como a cadeia de certificados é montado

Quando você executa o comando uipathctl config tls-certificates update , uipathctl monta a cadeia de certificados completa a partir de dois arquivos de entrada separados:

• server.crt a cadeia completa de certificados do servidor público no formato PEM: o certificado do servidor de folha, seguido pelo(s) certificado(s) de CA intermediários e a CA raiz que formam o caminho de assinatura para esse certificado de folha. Inclua apenas certificados que fazem parte da cadeia de assinatura real do certificado de folha — não inclua certificados de CA irmãos, não relacionados, duplicados ou alternativos.
• ca.crt a cadeia de CA completa, incluindo todos os certificados intermediários e a CA raiz. O arquivo deve conter apenas os certificados usados para assinar o certificado do servidor TLS. Incluir qualquer outra coisa levará à falha.

uipathctl esses arquivos no runtime.

Para atualizar o certificado, forneça o caminho para cada um dos três arquivos de certificado. Todos os arquivos de certificado devem estar em formato PEM .

• Pacote de autoridades de certificados - A cadeia de CA completa usada para assinar o certificado do servidor TLS. Inclua todos os certificados intermediários e a CA raiz. Não inclua o certificado leaf ou quaisquer outros certificados não usados para assinar o certificado do servidor TLS, pois incluir qualquer outra coisa levará a uma falha. O limite de cadeia é de até nove certificados.
• Certificado do servidor - A cadeia completa de certificados do servidor público no formato PEM, começando com o certificado leaf do servidor, seguida pelo(s) certificado(s) de CA intermediário e CA raiz. Inclui apenas os certificados que formam a cadeia de assinatura real do certificado de folha.
• Chave privada - Chave privada para o certificado do servidor.

./bin/uipathctl config tls-certificates update --cert server.crt --cacert ca.crt --key server.key

Para solucionar erros de validação de certificado TLS, consulte Erros de validação de certificado TLS.

Os arquivos a seguir são armazenados no local /directory/path/to/store/certificate .

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.

./bin/uipathctl config tls-certificates get --show-details

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:

./bin/uipathctl config additional-ca-certificates --help

Saída:

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

Manage additional ca certificates

Usage:
  uipathctl config additional-ca-certificates [flags]
  uipathctl config additional-ca-certificates [command]

Available Commands:
  get         Get the current additional ca certificates
  update      Update additional ca certificates

Flags:
  -h, --help   help for additional-ca-certificates

Global Flags:
      --context string      name of the kubeconfig context to use
  -f, --force               override all user prompts to true
      --kubeconfig string   kubectl configuration file (default: ~/.kube/config)
      --log-format string   log format. one of [text,json] (default "text")
      --log-level string    set log level. one of [trace,debug,info,error] (default "info")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default: 90 minutes) (default 1h30m0s)
      --versions string     optional path to versions file

Use "uipathctl config additional-ca-certificates [command] --help" for more information about a command.

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

As seguintes seções descrevem as operações que você pode realizar usando o comando uipathctl config additional-ca-certificates .

Atualização dos certificados de CA

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.

Para atualizar os certificados de CA, siga as seguintes etapas:

1. Atualize o arquivo cluster_config.json para apontar para o arquivo com additional_ca_certs. Para obter detalhes, consulte Configuração do certificado.

2. Aplique o manifesto:

   ./bin/uipathctl manifest apply cluster_config.json --versions versions.json
   

   Este comando pode falhar com erros como:

   Error: [failed to wait for application argocd/<app-name1>: timed out waiting for the condition,
   failed to wait for application argocd/<app-name2>: timed out waiting for the condition]]
   

   Independentemente da falha, prossiga para a etapa 3 para reiniciar as implantações e estabilizar o ambiente.

3. Reinicie manualmente todas as implantações e conjuntos com estado no namespace uipath :

   kubectl rollout restart deployment -n <uipath>
   kubectl rollout restart sts -n <uipath>
   

Observação:

Para anexar os certificados antigos, você deve usar o comando get da seção Acesso aos certificados de CA e anexá-los no arquivo do certificado de CA .pem que você deve fornecer no campo additional_ca_certs . 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:

 ./bin/uipathctl config additional-ca-certificates get

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

O Automation Suite oferece dois métodos para gerenciar a rotação de certificados de assinatura de token de identidade: automático e manual.

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

./bin/uipathctl config token-signing-certificates --help

Saída:

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

Manage token signing certificates

Usage:
  uipathctl config token-signing-certificates [flags]
  uipathctl config token-signing-certificates [command]

Available Commands:
  automatic-key-management Manage key management
  get                      Get the current token signing certificate
  rotate                   Rotate token signing certificates
  update                   Update future token signing certificate

Flags:
  -h, --help   help for token-signing-certificates

Global Flags:
      --context string      name of the kubeconfig context to use
  -f, --force               override all user prompts to true
      --kubeconfig string   kubectl configuration file (default: ~/.kube/config)
      --log-format string   log format. one of [text,json] (default "text")
      --log-level string    set log level. one of [trace,debug,info,error] (default "info")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default: 90 minutes) (default 1h30m0s)
      --versions string     optional path to versions file

Use "uipathctl config token-signing-certificates [command] --help" for more information about a command.

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

Importante:

Você pode usar um comprimento máximo de chave de 4096 bits para assinar certificados. Recomendamos enfaticamente que você use um comprimento de chave de pelo menos 512 bits (64 bytes) como uma prática recomendada.

A seção a seguir fornece detalhes sobre as operações que você pode realizar usando o comando uipathctl config token-signing-certificates .

Rotação automática de certificado

Rotação automática de certificados significa que o Automation Suite gerencia o ciclo de vida das chaves de assinatura. Isso inclui chaves rotativas a cada 90 dias, anunciando novas chaves 14 dias antes da rotação, mantendo as chaves antigas por 14 dias após a rotação e, depois, excluí-las quando o período de 14 dias terminar.

Se você estiver atualizando de uma versão mais antiga para 2.2510, a rotação automática de certificados será desabilitada por padrão. Para habilitar o gerenciamento automático de chaves, execute o seguinte comando:

./bin/uipathctl config token-signing-certificates automatic-key-management enable

Importante:

Habilitar a rotação automática de certificados pode resultar em um tempo de inatividade de até uma hora.

A rotação automática de certificados é habilitada por padrão para instalações limpas do Automation Suite. Para desabilitar o gerenciamento automático de chaves, execute o seguinte comando:

./bin/uipathctl config token-signing-certificates automatic-key-management disable

Se a funcionalidade de gerenciamento automático estiver desabilitada, os certificados de assinatura precisarão ser atualizados e girados manualmente. Para obter detalhes sobre o gerenciamento manual de chaves, consulte a documentação sobre atualização manual e rotação de certificado.

Atualização manual do certificado

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 . O arquivo server.crt deve conter toda a cadeia, conforme mostrado no exemplo a seguir:

-----server cert-----
-----root ca chain-----

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

./bin/uipathctl config token-signing-certificates update --cert server.crt --key server.key

Rotação manual do certificado

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

./bin/uipathctl config token-signing-certificates 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:

./bin/uipathctl config token-signing-certificates get --show-details

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