Trusted vs self-signed certificates
Overview
For end-user facing URLs it is recommended to use trusted and signed SSL certificates for HTTPS connections from the browser.
There are three main web endpoints: Control Tower and WorkSpace web interfaces, and static content resource endpoint (S3).
There can be either two separate certificates, or one certificate with wildcard domain name (or with SAN names) configured to support SSL connection.
WorkFusion Component Integration Security (RPA)
For the server-to-server communication between WorkFusion components, between Control Tower (App server) and RPA (VDI or Windows Server) in particular, the trust communication layer is established in the following way:
- RPA server certificates are used for bi-directional server-to-server communication between WorkFusion services
- Each of the servers where WorkFusion services are deployed has a truststore configured with a strict list of the certificates (or in other words - servers) allowed to be communicated with
Since the server-to-server communication trust is established based on the mutual truststores - usage of self-signed certificates is sufficient to establish secure communication channel. Introduction of Trusted certificates does not bring any additional advantage in security of this communication channel. However, if internal policies mandate usage of trusted and signed certificates, it’s possible to do so as well. It can be either a separate certificate for each VDI/server, or single certificate for several VDIs/servers having wildcard domain name or SAN names.