Certificates

The Work.AI platform requires a set of certificates that you must mandatorily prepare before the installation. Here, you have the following two alternatives:

• Generate self-signed certificates during the installation. If you decide to follow this way, you may skip this article. For more information, see the instructions.

• Use your own certificates.

  In this case, make sure that you have prepared and provided the following files:

  • server.crt
  • server.key
  • ca.crt

server.crt

Your server.crt can be any of the following types:

• Wildcard certificate

  For example, if all DNS names are in the same example.com domain zone, the certificate's CommonName in the cert subject must be .example.com.

• SAN certificate

  It must match all required Subject Alternative Names. See the example of the full list of Subject Alternative Names that certificate must match later.

  Note: if you plan to use more than two RPA or Agent servers, we recommend to include additional Subject Alternative Names into the certificate to match more DNS names. You can add the mentioned servers on-demand after the initial installation to scale environment capacity horizontally.

  For example, it will be wise to include rpa3.example.com, rpa4.example.com, and so on into certificate SANs. In this case, you won't have to regenerate the server certificate if, at some point, you have to add specific capacity to the environment.

The server.crt certificate must meet the following requirements:

• The certificate must be in the PEM format.

• The certificate must mandatorily include the end certificate and all intermediate ones if they exist.

  If you have several intermediate certificates in the chain, it is important to maintain the order of them, according to the rule: the subsequent one must sign the upper certificate in the file.

• The certificate's CommonName or Subject Alternative Names (SANs) must match all DNS names of all servers and all DNS names assigned to a load balancer. These names are later to be specified in hosts.yml.

  Example of domain names in SAN

  # For high availability setup
  
  master1.example.com
  master2.example.com
  master3.example.com
  agent1.example.com
  agent2.example.com
  agent3.example.com
  rpa1.example.com
  rpa2.example.com
  bi1.example.com
  bi2.example.com
  mssql.example.com
  vault-lb.example.com
  minio-lb.example.com
  nexus-lb.example.com
  rabbitmq-lb.example.com
  mesos-lb.example.com
  marathon-lb.example.com
  workspace-lb.example.com
  workfusion-lb.example.com
  bot-manager-lb.example.com
  kibana-lb.example.com
  ocr-lb.example.com
  bi-lb.example.com
  keycloak-lb.example.com
  
  # For single server setup
  
  master1.example.com
  agent1.example.com
  rpa1.example.com
  bi1.example.com
  mssql.example.com
  vault-lb.example.com
  minio-lb.example.com
  nexus-lb.example.com
  rabbitmq-lb.example.com
  mesos-lb.example.com
  marathon-lb.example.com
  workspace-lb.example.com
  workfusion-lb.example.com
  bot-manager-lb.example.com
  kibana-lb.example.com
  ocr-lb.example.com
  bi-lb.example.com
  keycloak-lb.example.com

server.key

server.key is a private key file for server.crt.

• The key must not be password-protected.

• The key must be in the PKCS#8 format and start with the line:

  -----BEGIN PRIVATE KEY-----

  End with the line:

  -----END PRIVATE KEY-----

  If your server.key starts with -----BEGIN RSA PRIVATE KEY-----, and ends with the line -----END RSA PRIVATE KEY-----, it means that your key file is in PKCS#1 format.

  You need to convert it to the PKCS#8 format using the below command:

  # go to certificates/ dir
  cd PACKAGE_DIR/certificates/
  
  # convert server.key from PKCS#1 format to PKCS#8 format. It will create new file: server.key_new
  openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in server.key -out server.key_new
  
  # replace old server.key with the newly generated one:
  mv server.key_new server.key

ca.crt

ca.crt is the certification authority (CA) bundle file.

• ca.crt must include a chain of all intermediate certificates, if they exist, and a Root CA certificate at the end of the chain.
• If there are no intermediate certs in the chain, ca.crt must include only the Root CA certificate.
• If there are multiple intermediate certs in the chain, the order of placing them in ca.crt does matter. The rule is the following: each certificate must sign the previous one.
• The first certificate in ca.crt bundle must sign server.crt.