証明書を管理する

重要:

インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。これらの証明書は 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 証明書をローテーションする

By default, RKE2 certificates expire in 12 months. In the 90 days prior to their expiration date, certificates are rotated when you restart RKE2. However, if the validity of the certificates exceeds the 90-day period, you must manually rotate the certificates by following the steps mentioned in RKE2 - Advanced Options - Certificate rotation.

If you want to customize the expiration period of RKE2 certificates to meet particular requirements, you can do so before restarting the RKE2 services for both server and agent nodes.

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

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

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

   systemctl stop rke2-server.service

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

   rke2-killall.sh

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

4. To customize the expiration period of the RKE2 certificates, use the following command. Be aware that this example sets the validity period to 1000 days, but you can change this value based on your requirements.

   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. To customize the expiration period of the RKE2 certificates, use the following command. Be aware that this example sets the validity period to 1000 days, but you can change this value based on your requirements.

   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