automation-suite
2.2510
true
Automation Suite on OpenShift installation guide
- Overview
- Requirements
- Pre-installation
- Preparing the installation
- Downloading the installation packages
- Configuring the OCI-compliant registry
- Granting installation permissions with cluster roles
- Granting installation permissions without cluster roles
- Installing and configuring the service mesh
- Installing and configuring the GitOps tool
- Installing the External Secrets Operator
- Deploying Redis through OperatorHub
- Applying miscellaneous configurations
- Running uipathctl
- Installation
- Post-installation
- Migration and upgrade
- Monitoring and alerting
- Cluster administration
- Product-specific configuration
- Orchestrator advanced configuration
- Configuring Orchestrator parameters
- Configuring appSettings
- Configuring the maximum request size
- Overriding cluster-level storage configuration
- Configuring NLog
- Saving robot logs to Elasticsearch
- Configuring credential stores
- Configuring encryption key per tenant
- Cleaning up the Orchestrator database
- Skipping host library installation
- AI Trust Layer
- Troubleshooting
- 500 errors and rate limiting on S3 requests in ODF
- External Secrets troubleshooting
- Configuring CSI driver tolerations for ODF 4.20
- Temporal as a Service troubleshooting
- AI Center and Document Understanding pods fail to start with TLS certificate verification enabled
- Studio Desktop cannot load Integration Service connectors and activities
- TLS certificate validation errors
- Manual ArgoCD NetworkPolicy mitigation (GHSA-47m3-95c7-g2g8)
- Configuring resource requests and limits for uipathctl-created workloads
Solutions for TLS certificate validation errors in Automation Suite on OpenShift.
If TLS certificate validation fails after updating the certificates in Automation Suite, refer to the following table to identify the cause and resolution.
| Error message (contains) | Cause | Resolution |
|---|---|---|
incomplete or untrusted certificate chain | A missing intermediate certificate, or the chain does not lead to the provided root CA. | Put all intermediate certificates and the root CA in ca.crt. |
is not part of the leaf certificate's chain | A certificate that did not issue the leaf is present (a sibling or unrelated intermediate, or a duplicate). | Ensure server.crt contains only the certificates from the leaf's actual signing chain — remove any sibling, unrelated, or duplicate CA certificates. Put the signing chain's intermediate(s) and root CA in ca.crt. |
certificates are not in the correct order | Certificates are out of order. | Order them: leaf certificate, then intermediate(s), then root CA. |
leaf certificate does not match fqdn | The leaf certificate's SAN omits the cluster FQDN, or server.crt does not start with the leaf. | Ensure server.crt begins with the leaf certificate and that the cluster FQDN is listed in its Subject Alternative Names. |
Certificate requirements
To ensure TLS certificate validation succeeds, ensure the certificate files meet the following requirements:
- The
server.crtfile must contain the complete public server certificate chain in PEM format. The chain must start with the leaf server certificate, followed by the intermediate CA certificate(s), and then the root CA that form the signing path for that leaf certificate. - The
server.crtfile must include only certificates that are part of the leaf certificate's actual signing chain. Do not include sibling, unrelated, duplicate, or alternate CA certificates, as TLS validation fails when certificates outside the leaf certificate's chain are present. - The
ca.crtfile must contain the CA certificate bundle used to validate the server certificate chain, including the required intermediate CA certificate(s) and root CA. Theca.crtfile must not include the leaf server certificate.