証明書を管理する

重要:

インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。これらの証明書は FIPS に対応しており、90 日で有効期限が切れるので、インストールが完了したら速やかに、信頼された証明機関 (CA) によって署名された証明書に置き換える必要があります。証明書を更新しないと、90 日でインストールが動作を停止します。

Automation Suite を FIPS が有効化されたホストにインストールした後で証明書を更新する場合は、その証明書が FIPS に対応していることを確認してください。

インストール バンドルでは、インストール後に証明書を更新できるクラスター管理ツールを提供しています。このツールにアクセスするには、インストーラー バンドルの保存場所に移動します。

cd /opt/UiPathAutomationSuite/

証明書署名要求 (CSR) と秘密キーを生成する

CSR および秘密キーを生成するには、次のコマンドを実行します。

# 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

IT チームが、取得した値を使用して署名証明書を生成します。生成された秘密キーはローカルのままです。

サーバー証明書を管理する

サーバー証明書の詳細情報を表示するには、次のコマンドを実行します。

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

出力:

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

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

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

以降のセクションでは、./configureUiPathAS.sh tls-cert コマンドを使用して実行できる操作について説明します。

サーバー証明書を更新する

オンライン インストール: サーバー証明書の確認方法

証明書は Istio レベルでシークレットとして保存されます。証明書は、istio-system 名前空間内に istio-ingressgateway-certs という名前で確認できます。

証明書ファイルについては、以下のリストをご覧ください。

• サーバー TLS 証明書は tls.crt として保存されます。
• サーバー TLS 秘密キーは tls.key として保存されます。
• CA バンドルは ca.crt として保存されます。

次のコマンドを使用して、シークレットを確認できます。

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

証明書は UiPath 名前空間にも保存されます。これは、受信呼び出しを信頼するために証明書情報を必要とするすべての UiPath® 製品に適用されます。詳細については、「証明書に関連するコンテナー アーキテクチャを理解する」をご覧ください。

オフライン インストール: サーバー証明書の確認方法

オフライン デプロイでは、オンライン デプロイで必要な証明書に加え、同じ rootCA.crt と tls.crt を使用する場所が他に 2 つあります。ArgoCD と Docker レジストリです。証明書は、Docker と ArgoCD の両方の名前空間に保存されます。

次のコマンドを使用して、シークレットを確認できます。

# 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

サーバー証明書の更新方法

重要: サーバー証明書を更新する前に、証明書キーを復号する必要があります。復号手順をスキップすると、エラーが発生します。

証明書キーを復号するには、次のコマンドを実行します。

# 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

以下に示すように、configureUiPathAS.sh スクリプトを実行し、証明書を更新します。3 つの証明書ファイルのそれぞれに対するパスが必要です。証明書ファイルは、いずれも PEM 形式である必要があります。

• 証明機関バンドル - このバンドルには TLS サーバー証明書への署名に使用するチェーン証明書のみを含める必要があります。チェーンの制限は最大 9 個の証明書です。
• サーバー証明書 - 公開サーバー証明書です。

• 秘密キー - サーバー証明書の秘密キーです。

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

下記のファイルは、/directory/path/to/store/certificate に保存されます。

TLS 証明書にアクセスする

証明書ファイルを出力するには、証明書が保存されているディレクトリを指定して、次のコマンドを実行します。

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

CA 証明書をホスト信頼ストアに追加する

生成された証明書が信頼できることを確認するのはユーザーの責任です。

証明書をホスト仮想マシンの信頼ストアに追加するには、クラスター内のすべてのノードで次のコマンドを実行します。

# 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

追加の CA 証明書を管理する

追加の CA 証明書の詳細情報を表示するには、次のコマンドを実行します。

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

出力:

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

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

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

以降のセクションでは、./configureUiPathAS.sh additional-ca-certs コマンドを使用して実行できる操作について説明します。

CA 証明書を更新する

このコマンドにより、既存の構成済み CA 証明書を更新または置換できます。

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

注:

上記のコマンドは、既存の証明書のリストに新しい証明書を追加します。以前に構成した証明書をすべて置き換える場合は、必ず末尾に --replace を付加してください。

CA 証明書バンドル ファイルは有効な .pem 形式である必要があり、複数の証明書を含めることができます。

CA 証明書にアクセスする

設定済みの CA 証明書をダウンロードするには、次のコマンドを実行します。

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

CA 証明書をホスト信頼ストアに追加する

生成された証明書が信頼できることを確認するのはユーザーの責任です。

証明書をホスト仮想マシンの信頼ストアに追加するには、クラスター内のすべてのノードで次のコマンドを実行します。

# 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

ID トークン署名証明書を管理する

追加の ID トークン署名証明書の詳細情報を表示するには、次のコマンドを実行します。

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

出力:

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

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

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

次のセクションでは、./configureUiPathAS.sh identity token-cert コマンドを使用して実行できる操作について詳しく説明します。

証明書を更新する

新しい証明書をアップロードしてトークンに署名するには、次のコマンドを実行します。

注:

次のコマンドでは、既存のトークン署名証明書は置換されません。

指定する証明書が .pem 形式であることを確認します。

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

証明書をローテーションする

古い証明書をローテーションしたり、新しい証明書に置換したりするには、次のコマンドを実行します。

sudo ./configureUiPathAS.sh identity token-cert rotate

注:

証明書の更新とローテーションの間には、約 24 - 48 時間のリード タイムが必要です。

このリード タイムは、キャッシュされている、古い証明書によって署名されたトークンの認証を引き続きサポートするために必要となります。

キャッシュ トークンの有効期限の満了を待たずに証明書をローテーションすると、ダウンタイムが発生する場合があります。さらに、すべてのロボットの再起動が必要になる可能性もあります。

証明書の緊急ローテーション

重要: 以下の手順は緊急時専用です。証明書は、有効期限前にローテーションする必要があります。

証明書の緊急更新を実行するには、次の手順に従います。

1. 新しい証明書を取得するか、自己署名証明書を作成して、次のローテーション手順を実行するために使用するクラスター サーバー ノードにコピーします。新しい自己署名証明書を作成するには、次のコマンドを実行します。

   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. IdentityServer1.pfx の有効期限が切れている場合は、証明書をローテーションおよび更新します。手順については、「証明書をローテーションする」をご覧ください。
3. IdentityServer2.pfx の有効期限が切れている場合は、証明書を更新します。
4. 両方の証明書の有効期限が切れている場合は、更新してローテーションし、もう一度更新します。
5. すべてのデプロイを再起動します。
6. すべてのブラウザー キャッシュをクリアします。シークレット モードまたはプライベート モードで実行する場合、この手順はスキップできます。
7. Firefox の場合は、CTRL + SHIFT + DEL を押し、[キャッシュ] を選択して [OK] をクリックします。
   
   

   

   
   
8. Chrome の場合は、CTRL + SHIFT + DEL キーを押し、[キャッシュされた画像とファイル] を選択して [データを削除] をクリックします。
   
   

   

   
   

証明書にアクセスする

現在のトークン署名証明書をダウンロードするには、次のコマンドを実行します。

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

RKE2 証明書を管理する

既定では、RKE2 証明書は 12 か月で有効期限が切れます。有効期限の 90 日前に RKE2 を再起動すると、証明書がローテーションされます。

詳細については、「RKE2 - Advanced Options - Certificate rotation」をご覧ください。

RKE2 証明書の有効期限を確認する

RKE2 証明書の有効期限を確認するには、任意のノードで次のコマンドを実行します。

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

得られる出力は、次の画像のようになります。

RKE2 証明書をローテーションする

既定では、RKE2 証明書は 12 か月で有効期限が切れます。 有効期限の 90 日前に RKE2 を再起動すると、証明書がローテーションされます。 ただし、証明書の有効期間が 90 日を超える場合は、「 RKE2 - Advanced Options - Certificate rotation」に記載されている手順に従って、証明書を手動でローテーションする必要があります。

特定の要件を満たすように RKE2 証明書の有効期限をカスタマイズする場合は、サーバー ノードとエージェント ノードの両方で RKE2 サービスを再起動する前にカスタマイズできます。

RKE2 の証明書をローテーションするには、最初にサーバー ノードで一連の操作を実行してから、エージェント ノードでいくつかの手順を続行します。

サーバー ノードで次の手順を実行します。

1. RKE2 サーバーを停止します。

   systemctl stop rke2-server.service

2. 残りの RKE2 プロセスをすべてクリアします。

   rke2-killall.sh

3. /var/lib/rancher/rke2/server/tls/ にある dynamic-cert.json ファイルを削除します。

4. RKE2 証明書の有効期限をカスタマイズするには、次のコマンドを使用します。 この例では有効期間を 1000 日に設定していますが、この値は要件に基づいて変更できます。

   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. RKE2 サーバーを再起動します。

   systemctl start rke2-server.service

   注: クラスターに複数のサーバー ノードがある場合、手順 1 から 4 を完全には実行できないことがあります。これは etcd がリーダーの選出を完了できないためです。この場合は、他のサーバー ノードで手順 1 から 4 を繰り返します。
6. kube-system 名前空間から rke2-serving シークレットを削除します。

   kubectl delete secret -n kube-system rke2-serving

   注:

   マルチノード デプロイでは、必要な数のサーバー ノードで最初の 4 つの操作を完了するまで、kubectl コマンドを実行できない場合があります。これは、etcd クォーラム要件を満たすためです。rke2-serving シークレットは、RKE2 サーバーが起動したらすぐに削除できます。

etcd がクォーラムに達すると、RKE2 サーバーは残りのコントロール プレーン ポッドを起動できます。すると、kubectl get nodes コマンドが正常に実行されたことを確認できます。サーバー ノードの準備ができたら、エージェント ノードの操作に進んで証明書を再生成できます。

エージェント ノードで次の手順を実行します。

1. RKE2 サーバーを停止します。

   systemctl stop rke2-agent.service

2. 残りの RKE2 プロセスをすべてクリアします。

   rke2-killall.sh

3. RKE2 証明書の有効期限をカスタマイズするには、次のコマンドを使用します。 この例では有効期間を 1000 日に設定していますが、この値は要件に基づいて変更できます。

   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. RKE2 サーバーを再起動します。

   systemctl start rke2-agent.service