Verwalten der Zertifikate

Wichtig:

Der Installationsprozess generiert selbstsignierte Zertifikate in Ihrem Namen. Diese Zertifikate sind FIPS-konform und laufen in 90 Tagen ab. Sie müssen sie durch Zertifikate ersetzen, die von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert wurden, sobald die Installation abgeschlossen ist. Wenn Sie die Zertifikate nicht aktualisieren, funktioniert die Installation nach 90 Tagen nicht mehr.

Wenn Sie die Automation Suite auf einem FIPS-fähigen Host installiert haben und die Zertifikate aktualisieren möchten, stellen Sie sicher, dass sie mit FIPS kompatibel sind.

Das Installationspaket bietet ein Clusterverwaltungstool, mit dem Sie Zertifikate nach der Installation aktualisieren können. Um auf das Tool zuzugreifen, navigieren Sie zum Speicherort des Installationspakets:

cd /opt/UiPathAutomationSuite/

Generieren einer Certificate Signing Request (CSR) und eines privaten Schlüssels

Führen Sie den folgenden Befehl aus, um die CSR und den privaten Schlüssel zu generieren:

# 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

Ihr IT-Team verwendet die erhaltenen Werte, um ein signiertes Zertifikat zu generieren. Der generierte private Schlüssel bleibt lokal.

Verwalten von Serverzertifikaten

Um weitere Informationen zu Serverzertifikaten anzuzeigen, führen Sie den folgenden Befehl aus:

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

Ausgabe:

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

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
      --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 "error")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default 1h0m0s)

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

In den folgenden Abschnitten werden die Vorgänge beschrieben, die Sie mit dem Befehl uipathctl config tls-certificates ausführen können.

Aktualisieren der Clusterzertifikate

Online-Installation: So finden Sie das Serverzertifikat

Zertifikate werden als Geheimnis auf Istio-Ebene gespeichert. Zertifikate finden Sie unter dem Namen istio-ingressgateway-certs im Namespace istio-system .

Sehen Sie sich die Zertifikatsdateien in der folgenden Liste an:

• Das Server-TLS-Zertifikat wird als tls.crt gespeichert.
• Privater Server-TLS-Schlüssel als tls.key
• CA-Paket wird als ca.crt gespeichert.

Sie können die Geheimnisse mit dem folgenden Befehl überprüfen:

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

Zertifikate werden auch im UiPath-Namespace gespeichert. Das gilt für jedes UiPath®-Produkt, das Zertifikatinformationen benötigt, um eingehenden Aufrufen zu vertrauen. Weitere Informationen finden Sie unter Grundlegendes zur Containerarchitektur bezüglich Zertifikaten.

Offlineinstallation: So finden Sie das Serverzertifikat

Zusätzlich zu den Zertifikaten, die für die Onlinebereitstellung erforderlich sind, gibt es bei einer Offlinebereitstellung zwei weitere Speicherorte, die die gleiche rootCA.crt und tls.crtverwenden: ArgoCD und Docker-Registrierung. Die Zertifikate werden dann sowohl im Docker- als auch im ArgoCD-Namespace gespeichert.

Sie können die Geheimnisse mit dem folgenden Befehl überprüfen:

# 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

So aktualisieren Sie Serverzertifikate

Wichtig: Sie müssen den Zertifikatschlüssel entschlüsseln, bevor Sie das Serverzertifikat aktualisieren. Das Überspringen des Entschlüsselungsschritts würde zu einem Fehler führen.

Führen Sie den folgenden Befehl aus, um den Zertifikatschlüssel zu entschlüsseln:

# 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

Führen Sie uipathctl aus, um das Zertifikat zu aktualisieren. Sie benötigen den Pfad zu jeder der drei Zertifikatsdateien. Alle Zertifikatsdateien müssen das Format PEM haben.

• Zertifizierungsstellenpaket – Dieses Paket sollte nur die Kettenzertifikate enthalten, die zum Signieren des TLS-Serverzertifikats verwendet werden. Das Kettenlimit beträgt bis zu neun Zertifikate.

• Serverzertifikat – Öffentliches Serverzertifikat

  Hinweis:

  Die Datei server.crt muss die gesamte Kette enthalten, wie im folgenden Beispiel gezeigt:

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

• Privater Schlüssel – Privater Schlüssel für das Serverzertifikat

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

Die folgenden Dateien werden unter /directory/path/to/store/certificate gespeichert.

Zugriff auf das TLS-Zertifikat

Zum Ausgeben der Zertifikatsdateien führen Sie den folgenden Befehl aus, wobei Sie das Verzeichnis angeben, in dem die Zertifikate gespeichert sind.

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

Hinzufügen des Zertifizierungsstellenzertifikats zum Host-Truststore

Sie sind dafür verantwortlich, sicherzustellen, dass die generierten Zertifikate vertrauenswürdig sind.

Um das Zertifikat zum Host-VM-Truststore hinzuzufügen, führen Sie die folgenden Befehle auf allen Knoten im Cluster aus:

# 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

Verwalten zusätzlicher Zertifikate von Zertifizierungsstellen

Um weitere Informationen über zusätzliche Zertifikate von Zertifizierungsstellen anzuzeigen, führen Sie den folgenden Befehl aus:

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

Ausgabe:

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

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
      --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 "error")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default 1h0m0s)

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

In den folgenden Abschnitten werden die Vorgänge beschrieben, die Sie mit dem Befehl uipathctl config additional-ca-certificates ausführen können.

Aktualisieren der Zertifikate von Zertifizierungsstellen

Bevor Sie den Befehl ausführen, müssen Sie die Datei cluster_config.json aktualisieren, damit sie auf die Datei mit additional_ca_certs verweist. Weitere Informationen zu diesem Parameter finden Sie unter Zertifikatkonfiguration.

Mit diesem Befehl können Sie die vorhandenen konfigurierten Zertifizierungsstellenzertifikate aktualisieren oder ersetzen.

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

Hinweis:

Um die alten Zertifikate anzufügen, müssen Sie den Befehl get aus dem Abschnitt Zugriff auf die Zertifikate von Zertifizierungsstellen verwenden und sie in der Datei .pem des Zertifizierungsstellenzertifikats anfügen, die Sie im Feld additional_ca_certs angeben müssen.

Die Zertifikatspaketdatei von der Zertifizierungsstelle muss in einem gültigen .pem-Format sein und kann mehr als ein Zertifikat enthalten.

Zugriff auf das Zertifikat von einer Zertifizierungsstelle

Um die bereits konfigurierten Zertifikate von Zertifizierungsstellen herunterzuladen, führen Sie den folgenden Befehl aus:

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

Hinzufügen des Zertifizierungsstellenzertifikats zum Host-Truststore

Sie sind dafür verantwortlich, sicherzustellen, dass die generierten Zertifikate vertrauenswürdig sind.

Um das Zertifikat zum Host-VM-Truststore hinzuzufügen, führen Sie die folgenden Befehle auf allen Knoten im Cluster aus:

# 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

Verwalten von Identitätstoken-Signaturzertifikaten

Die Automation Suite bietet zwei Methoden, um die Rotation von Identitätstoken-Signaturzertifikaten zu verwalten: automatisch und manuell.

Um weitere Informationen zu Identitätstoken-Signaturzertifikaten anzuzeigen, führen Sie den folgenden Befehl aus:

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

Ausgabe:

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

Manage token signing certificates

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

Available Commands:
  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
      --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 "error")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default 1h0m0s)

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

Wichtig:

Sie können eine maximale Schlüssellänge von 4096 Bit zum Signieren von Zertifikaten verwenden. Als Best Practice empfehlen wir dringend, eine Schlüssellänge von mindestens 512 Bit (64 Byte) zu verwenden.

Im folgenden Abschnitt finden Sie Details zu den Vorgängen, die Sie mit dem Befehl uipathctl config token-signing-certificates ausführen können.

Automatische Zertifikatsrotation

Automatische Zertifikatsrotation bedeutet, dass die Automation Suite den Lebenszyklus der Signaturschlüssel verwaltet. Dazu gehören das Rotieren von Schlüsseln alle 90 Tage, die Ankündigung neuer Schlüssel 14 Tage vor der Rotation, die Aufbewahrung alter Schlüssel für 14 Tage nach der Rotation und das Löschen nach Ablauf des 14-Tage-Zeitraums.

Wenn Sie von einer älteren Version auf 2024.10 aktualisieren, ist die automatische Zertifikatsrotation standardmäßig deaktiviert. Um die automatische Schlüsselverwaltung zu aktivieren, verwenden Sie den folgenden Befehl:

uipathctl config token-signing-certificates automatic-key-management enable

Wichtig:

Die Aktivierung der automatischen Zertifikatsrotation kann zu einer Ausfallzeit von bis zu einer Stunde führen.

Die automatische Zertifikatsrotation ist standardmäßig für Neuinstallationen der Automation Suite aktiviert. Um die automatische Schlüsselverwaltung zu deaktivieren, verwenden Sie den folgenden Befehl:

uipathctl config token-signing-certificates automatic-key-management disable

Wenn die automatische Verwaltungsfunktion deaktiviert ist, müssen Signaturzertifikate manuell aktualisiert und rotiert werden. Weitere Informationen zur manuellen Schlüsselverwaltung finden Sie in der Dokumentation zum manuellen Aktualisieren und Rotieren des Zertifikats.

Manuelles Aktualisieren des Zertifikats

Führen Sie den folgenden Befehl aus, um das neue Zertifikat zum Signieren des Tokens hochzuladen:

Hinweis:

Der folgende Befehl ersetzt nicht das vorhandene Tokensignaturzertifikat.

Stellen Sie sicher, dass das von Ihnen bereitgestellte Zertifikat das Format .pem hat.

Die Datei server.crt muss die gesamte Kette enthalten, wie im folgenden Beispiel gezeigt:

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

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

Manuelles Rotieren des Zertifikats

Um das alte Zertifikat zu rotieren oder durch das neue zu ersetzen, führen Sie den folgenden Befehl aus:

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

Hinweis:

Die Vorlaufzeit zwischen der Zertifikat-Aktualisierung und dem Rotieren sollte etwa 24 bis 48 Stunden betragen.

Wir benötigen diese Vorlaufzeit, um die Authentifizierung für zwischengespeicherte Token, die von einem alten Zertifikat signiert wurden, weiterhin unterstützen zu können.

Wenn Sie das Zertifikat zu früh vor dem Ablauf des Cache-Tokens rotieren, kann dies zu Ausfallzeiten führen. Möglicherweise müssen Sie dann auch alle Ihre Roboter neu starten.

Notfall-Zertifikatsrotation

Wichtig: Das folgende Verfahren gilt nur für Notfälle. Sie sollten Zertifikate vor ihrem Ablaufdatum rotieren

Führen Sie die folgenden Schritte aus, um eine Notfall-Zertifikatsaktualisierung durchzuführen:

1. Rufen Sie ein neues Zertifikat ab oder erstellen Sie ein selbstsigniertes Zertifikat und kopieren Sie es auf den Clusterserverknoten, der zum Ausführen der nächsten Rotationsschritte verwendet wird. Führen Sie den folgenden Befehl aus, um ein neues selbstsigniertes Zertifikat zu erstellen:

   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. Wenn IdentityServer1.pfx abgelaufen ist, rotieren und aktualisieren Sie das Zertifikat. Anweisungen finden Sie unter Rotieren des Zertifikats.
3. Wenn IdentityServer2.pfx abgelaufen ist, aktualisieren Sie das Zertifikat.
4. Wenn beide Zertifikate abgelaufen sind, aktualisieren, rotieren und erneut aktualisieren.
5. Starten Sie alle Bereitstellungen neu.
6. Löschen Sie alle Browser-Caches. Wenn Sie im Inkognito- oder privaten Modus ausführen, können Sie diesen Schritt überspringen.
7. Drücken Sie bei Firefox auf STRG+UMSCHALT+ENTF, wählen Sie Cache aus und dann OK.
   
   

   

   
   
8. Drücken Sie bei Chrome STRG+UMSCHALT+ENTF, wählen Sie Im Cache gespeicherte Bilder und Dateien und dann Daten löschen aus.
   
   

   

   
   

Zugreifen auf das Zertifikat

Führen Sie den folgenden Befehl aus, um das aktuelle Tokensignaturzertifikat herunterzuladen:

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

Verwalten von RKE2-Zertifikaten

Standardmäßig laufen RKE2-Zertifikate in 12 Monaten ab. In den 90 Tagen vor ihrem Ablaufdatum werden Zertifikate rotiert, wenn Sie RKE2 neu starten.

Weitere Informationen finden Sie unter RKE2 – Erweiterte Optionen – Zertifikatsrotation.

Überprüfen des Ablaufdatums des RKE2-Zertifikats

Um das Ablaufdatum des RKE2-Zertifikats zu überprüfen, führen Sie den folgenden Befehl auf einem der Knoten aus:

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

Die Ausgabe, die Sie erhalten, sollte in etwa so aussehen wie im folgenden Bild:

Rotieren des RKE2-Zertifikats

Standardmäßig laufen RKE2-Zertifikate in 12 Monaten ab. In den 90 Tagen vor ihrem Ablaufdatum werden Zertifikate rotiert, wenn Sie RKE2 neu starten. Wenn die Gültigkeit der Zertifikate jedoch den Zeitraum von 90 Tagen überschreitet, müssen Sie die Zertifikate manuell rotieren, indem Sie die unter RKE2 – Erweiterte Optionen – Zertifikatsrotation genannten Schritte ausführen.

Wenn Sie den Ablaufzeitpunkt von RKE2-Zertifikaten an bestimmte Anforderungen anpassen möchten, ist dies möglich, bevor Sie die RKE2-Dienste für Server- und Agent-Knoten neu starten.

Um die RKE2-Zertifikate zu rotieren, müssen Sie zuerst eine Reihe von Aktionen auf den Serverknoten ausführen und dann mit einigen Schritten für die Agent-Knoten fortfahren.

Führen Sie die folgenden Schritte auf den Serverknoten aus:

1. Stoppen Sie den RKE2-Server:

   systemctl stop rke2-server.service

2. Löschen Sie alle verbleibenden RKE2-Prozesse:

   rke2-killall.sh

3. Löschen Sie die Datei dynamic-cert.json unter /var/lib/rancher/rke2/server/tls/.

4. Um den Ablaufzeitraum der RKE2-Zertifikate anzupassen, verwenden Sie den folgenden Befehl. Beachten Sie, dass in diesem Beispiel der Gültigkeitszeitraum auf 1000 Tage festgelegt wird, Sie können diesen Wert jedoch basierend auf Ihren Anforderungen ändern.

   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. Starten Sie den RKE2-Server neu:

   systemctl start rke2-server.service

   Hinweis: Wenn der Cluster über mehrere Serverknoten verfügt, werden die Schritte 1–4 möglicherweise nicht vollständig ausgeführt, da etcd den Ringalgorithmus eventuell nicht abschließen kann. Wiederholen Sie in diesem Fall die Schritte 1–4 auf anderen Serverknoten.
6. Löschen Sie das Geheimnis rke2-serving aus dem Namespace kube-system:

   kubectl delete secret -n kube-system rke2-serving

   Hinweis:

   Bei einer Bereitstellung mit mehreren Knoten können Sie die kubectl-Befehle möglicherweise erst ausführen, wenn Sie die ersten vier Vorgänge auf der erforderlichen Anzahl von Serverknoten abgeschlossen haben. Damit wird die Quorum-Anforderung von etcd erfüllt. Sie können das Geheimnis rke2-serving sofort nach dem Start des RKE2-Servers entfernen.

Sobald etcd das Quorum erreicht hat, kann der RKE2-Server die restlichen Pods der Steuerungsebene starten. Der Befehl kubectl get nodes sollte dann erfolgreich ausgeführt werden. Wenn Ihre Serverknoten bereit sind, können Sie mit den Agent-Knoten fortfahren, um die Zertifikate neu zu generieren.

Führen Sie die folgenden Schritte auf den Agent-Knoten aus:

1. Stoppen Sie den RKE2-Server:

   systemctl stop rke2-agent.service

2. Löschen Sie alle verbleibenden RKE2-Prozesse:

   rke2-killall.sh

3. Um den Ablaufzeitraum der RKE2-Zertifikate anzupassen, verwenden Sie den folgenden Befehl. Beachten Sie, dass in diesem Beispiel der Gültigkeitszeitraum auf 1000 Tage festgelegt wird, Sie können diesen Wert jedoch basierend auf Ihren Anforderungen ändern.

   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. Starten Sie den RKE2-Server neu:

   systemctl start rke2-agent.service

Verwalten des externen OCI-konformen Registrierungszertifikats

Um das Zertifikat nach der Installation für die externe OCI-konforme Registrierung zu aktualisieren, führen Sie die folgenden Schritte aus:

1. Aktualisieren Sie das Flag registry_ca_cert in der Datei cluster_config.json . Weitere Informationen finden Sie unter Konfiguration der externen OCI-konformen Registrierung.
2. Aktualisieren Sie die Stammzertifizierungsstelle, die von der externen OCI-konformen Registrierung verwendet wird, indem Sie den folgenden Befehl auf allen Knoten ausführen:

   ./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. Aktualisieren Sie das ArgoCD-Zertifikat der vertrauenswürdigen Zertifizierungsstelle für die externe OCI-konforme Registrierung:

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