- Overview
- Requirements
- Pre-installation
- Installation
- Post-installation
- Migration and upgrade
- Upgrading Automation Suite
- Migrating standalone products to Automation Suite
- Step 1: Restoring the standalone product database
- Step 2: Updating the schema of the restored product database
- Step 3: Moving the Identity organization data from standalone to Automation Suite
- Step 4: Backing up the platform database in Automation Suite
- Step 5: Merging organizations in Automation Suite
- Step 6: Updating the migrated product connection strings
- Step 7: Migrating standalone Orchestrator
- Step 8: Migrating standalone Insights
- Step 9: Migrating standalone Test Manager
- Step 10: Deleting the default tenant
- Performing a single tenant migration
- Migrating between Automation Suite clusters
- Migrating from Automation Suite on EKS/AKS to Automation Suite on OpenShift
- 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 creation
- Troubleshooting
- The backup setup does not work due to a failure to connect to Azure Government
- Pods in the uipath namespace stuck when enabling custom node taints
- Unable to launch Automation Hub and Apps with proxy setup
- Robot cannot connect to an Automation Suite Orchestrator instance
- Log streaming does not work in proxy setups
- Velero backup fails with FailedValidation error
- Accessing FQDN returns RBAC: access denied error
Automation Suite on EKS/AKS installation guide
Certificate requirements
For details on how to manage certificates post-installation, see Managing certificates.
Automation Suite requires two certificates at the time of installation.
- TLS certificate - required for TLS communication between the client and the cluster;
- Identity token-signing certificate - required to sign the authentication token.
The installation process generates self-signed certificates on your behalf. We recommend that you replace them with certificates signed by a trusted Certificate Authority (CA). Note that the certificates can be generated at the time of installation only if you grant the Automation Suite installer admin privileges during the installation. If you cannot grant the installer admin privileges, then you must create and manage the certificates yourself.
Aside from the previous certificates, you may need to provide additional trusted CA certificates if you want the cluster to trust external software. Example: SQL Server CA Certificate, SMTP Server CA Certificate, external S3 compatible objectstore CA certificate, etc.
At the time of installation, you must provide CA certificates for any external software that requires a secure TLS communication. However, if you have not enabled the TLS communication, you can configure it post-installation.
For instructions, see Managing certificates.
TLS certificate requirements
The TLS certificate must meet the following requirements:
- File format should be
.pem, i.e., Base64 encoded DER certificate; - Private key length should be at least 2048;
- Extended Key Usage: TLS Web Server Authentication; required for accessing Automation Suite on iOS devices;
- Certificate key must be decrypted. If the key is encrypted, run the following command to decrypt it:
# 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# 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 - Should have Subject Alternative Name for all the DNS entries required for installing Automation Suite. If the FQDN for the cluster is
automationsuite.mycompany.com, the certificate SAN should have the following DNS:automationsuite.mycompany.com*.automationsuite.mycompany.comNote:Alternatively, if the
*wildcard is too generic, make sure you have SAN entries for the following DNS:automationsuite.mycompany.comalm.automationsuite.mycompany.commonitoring.automationsuite.mycompany.cominsights.automationsuite.mycompany.comapps.automationsuite.mycompany.com
TLS certificate file
Automation Suite requires three files at the time of installation, as follows:
- TLS certificate file - the server's public certificate file. This file must contain only the leaf server certificate.
- TLS key file - private key file for the server certificate.
- Certificate Authority Bundle - this is the Public Certificate of CA which is used to sign or issue the TLS certificate. This file must contain the complete certificate chain, including the root CA and all intermediate certificates.
Starting with Automation Suite 2024.10.8, partial chains - providing only the leaf certificate and root CA without intermediate certificates - are no longer accepted. TLS validation will fail if the certificate chain is incomplete.
To verify the CA and TLS certificate, run the following command on the Linux machine:
# Please replace /path/to/ca-certificate-bundle and /path/to/server-certificate with actual file path.
openssl verify -CAfile /path/to/ca-certificate-bundle /path/to/server-certificate
# Please replace /path/to/ca-certificate-bundle and /path/to/server-certificate with actual file path.
openssl verify -CAfile /path/to/ca-certificate-bundle /path/to/server-certificate
If you choose to bring your own Cert Manager, and your TLS certificate is issued by a private or non-public CA, you must manually include both the leaf certificate and intermediate CA certificates in the TLS certificate file. In case of public CAs, they are automatically trusted by client systems, and no further action is required on your part.
Identity token-signing certificate
Automation Suite has the following requirements in terms of token-signing certificates at the time of installation:
- File format should be
pkcs12to sign the authentication token; - Password for signing the certificate is required.
If an identity token signing certificate is not provided, Automation Suite uses the server certificates to generate the one at the time of installation.