Certificate Issues in Automation Suite - Troubleshooting Guide

News Knowledge Base
1

How to debug certificate issues in Automation Suite

This article describes how to debug certificate issues in Automation Suite.

CSR Generated Incorrectly

The CSR must include a [SAN] extension block with all required Automation Suite subdomains.

If the CSR is generated without the domains, the resulting certificate will be missing Subject Alternative Names. Modern browsers and Kubernetes components reject certificates that have a CN but no SAN.

Common mistakes include forgetting subdomains such as alm., monitoring., registry., objectstore., insights., or apps.

The correct CSR generation can be found in the Docs: Automation Suite - Managing the certificates

Verify the CSR has SANs before submitting to CA:

openssl req -text -noout -in automationsuite.maf.ae.csr | grep -A5 "Subject Alternative"

Wrong AS_FQDN in the CSR

The CN and SAN entries in the certificate do not match what is actually configured as the cluster FQDN - browsers, robots, and Istio all reject the certificate with TLS errors.

Evidence from this cluster: The Istio proxy logs show the actual FQDN in use. If the CSR was generated with a different value (e.g., a short hostname, an IP, or a staging FQDN), every HTTPS request would fail TLS verification.

This is how you check the deployed certificate's SANs:

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

or directly from the secret:

kubectl -n istio-system get secret istio-ingressgateway-certs -o jsonpath='{.data.tls\.crt}' \

| base64 -d | openssl x509 -text -noout | grep -A5 "Subject Alternative"

What to look for:

  • SANs must include all 7 entries: the base FQDN plus alm., monitoring., registry., objectstore., insights., apps. Subdomains or a wildcard can be used to include all *.FQDN
  • If the FQDN is wrong you must generate a new CSR with the correct AS_FQDN, obtain a new certificate from your CA, and then update it.

Automation Suite Server Certificate Expired

The self-signed certificate generated at install time expires in 90 days. If not replaced with a CA signed certificate, the entire platform becomes inaccessible.

How to check expiry:

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

How to update the server certificate (reference here):

  1. Decrypt the private key if it is encrypted:

openssl rsa -in /path/to/encrypted/server.key -out /path/to/decrypted/server.key

  1. Ensure server.crt contains the full chain (leaf + intermediate + root):

-----BEGIN CERTIFICATE----- ← server cert

...

-----BEGIN CERTIFICATE----- ← root CA chain

…

  1. Run the update:

./bin/uipathctl config tls-certificates update \

--cert server.crt \

--cacert ca.crt \

--key server.key

Note: Certificates are stored in the istio-ingressgateway-certs secret in the istio-system namespace and mirrored into the uipath namespace. Both locations are updated by uipathctl.

RKE2 Certificate Expired

The kube-apiserver log will show the KubeClientCertificateExpiration critical alert.

By default, RKE2 certificates expire after 12 months and auto-rotate only within the 90-day window before expiry (on service restart). If the cluster was never restarted in that window, the certificates expire.

  1. Check expiry on any node as mentioned in the Docs here.
  2. Rotate RKE2 certificates on each server node (repeat for all server nodes):

  1. Stop RKE2

systemctl stop rke2-server.service

  1. Kill remaining processes

rke2-killall.sh

  1. Delete the dynamic cert file

rm /var/lib/rancher/rke2/server/tls/dynamic-cert.json

  1. (Recommended) Extend validity to avoid recurrence

mkdir -p /etc/systemd/system/rke2-server.service.d/

cat > /etc/systemd/system/rke2-server.service.d/cert.conf <<EOF

[Service]

Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000"

EOF

systemctl daemon-reload

  1. Restart

systemctl start rke2-server.service

  1. Delete the serving secret so it regenerates:

kubectl delete secret -n kube-system rke2-serving

On each agent node:

systemctl stop rke2-agent.service

rke2-killall.sh

mkdir -p /etc/systemd/system/rke2-agent.service.d/

cat > /etc/systemd/system/rke2-agent.service.d/cert.conf <<EOF

[Service]

Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000"

EOF

systemctl daemon-reload

systemctl start rke2-agent.service

Important: In a multi-node cluster, perform steps 1–4 on the minimum number of server nodes needed to reach etcd quorum (at least 2 of 3) before running kubectl commands. The kubectl delete secret step can be done as soon as the RKE2 server starts.

After certs are rotated, Redis, config-discovery, and Orchestrator should self-recover.

If not, delete the stuck recovery job pod to unblock Redis:

kubectl delete pods -n redis-system -l job-name=redis-cluster-recovery-job --field-selector=status.phase=Running

Identity Certificate Expired

In case the automatic certificate rotation is not enabled and the platform is not reachable anymore (for example, getting a no healthy upstream error message), it might be that the identity certificate expired.

This can be confirmed by looking into the errors from the orchestrator and identity-server-api logs.

Look for: IdentityServer4.Services.DefaultTokenCreationService Certificate CN=xxxxxxxx, OU=xxxxxx, O=xxxxxxxx , L=xxxxxx, C=US has expired on …

It can be also confirmed by running the diagnostic tool here.

In case the identity certificate has expired, follow the steps in the Docs here to renew it.

Note: For different Automation Suite versions, adjust the documentation version from the drop-down button to match your current version.