There are three types of Secure Sockets Layer (SSL) certificates that you can install to enable single sign-on for the solutions that you create with Pega Robotic Automation. You install the certificates on a computer that is running Pega Robot Runtime. This computer must also use either Active Directory Federated Services (AD FS) or the Pega Robotic Automation Security Token Service (STS) to authenticate the Pega Robot Runtime and Studio products with the Pega Robot Manager.

Depending on your situation, install one of these certificates on a Pega Robot Runtime (client) machine.

• Self-signed SSL

A self-signed SSL certificate is an SSL certificate in which the root authority and identifying entity are the same. In this case, the self-signed certificate should be stored only under the Trusted Root Certification Authorities store.

• Internal CA SSL

There are situations in which your organization may require you to use your own internal Certificate Authority. In this case, the SSL certificate's path reflects two or more certificates in the certificate chain. The top-level certificate serves as the SSL root certificate with an internal CA-issued certificate underneath. Only place the root certificate in the Trusted Root Certification Authorities store.

For example, if you already have an internal CA, you might want to use it for SSL certificates in non-testing environments. With an internal CA, you only have to deploy its root certificate to the client desktops once and then all of the local servers with SSL certificates issued by that CA are validated. In contrast, when using self-signed certificates, each server’s certificate must be deployed to the client desktops and updated each time they are renewed. Using an internal CA can reduce the effort and complexity of establishing and revoking trust on client desktops.

• External CA SSL (third-party issue)

You can also choose to use an external CA or third-party issued certificate as the server's SSL certificate. Typically, you have already established trust with the external CA when you choose this option. You must verify that this trust has been established by checking for the SSL's root authority certificate under the Trusted Root Certification Authorities store of the client through the machine or current user profile. If for some reason, it is not found in either profile, test to see if communication to the AD FS or STS server is preset by group policy. If you cannot establish communication during testing, install the third-party SSL's root certificate to the Trusted Root Certification Authorities store on the client machine.

Best practices

The general rule is to always establish the trust to the AD FS or STS server by installing the SSL's root certificate to the Trusted Root Certification Authorities store. Adding the SSL intermediate and entity certificates does not assist in establishing trust. The trust is established solely through the root certificate. When establishing the connection to the STS or AD FS server, the client machine is presented with the full SSL certificate that is being published from the server side. The client only checks to see if the root that is presented by the server is found in the Trusted Root Certification Authorities store. It does not matter whether the root is installed using the machine or current user profile.

Troubleshooting

Build path errors can occur if intermediate certificates are missing from the publication of the SSL from the server. To handle such errors, republish the SSL certificate from the server, including the intermediate certificates, or add intermediate access information to the root certificate. This access information would include the URL site locations from to download the intermediate certificates from the client machine.