10.1.6

Edit

Certificates

Workfusion Intelligent Automation Cloud 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 type:

  • Wildcard certificate.

    For example, if all DNS names are in the same domain zone 'example.com', the certificate's CommonName in 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, OCR, or BEP 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, ocr3.example.com, etc. into certificate SANs. In this case you won't have to re-generate 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 order of them, according to the rule: the upper certificate in the file must be signed by the subsequent one.

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

    Example of domain names in SAN...

    # For high availability setup

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
int1.example.com
int2.example.com
int3.example.com
ct1.example.com
ct2.example.com
ocr1.example.com
ocr2.example.com
bi1.example.com
bi2.example.com
bepmaster1.example.com
bepmaster2.example.com
bepmaster3.example.com
bepagent1.example.com
bepagent2.example.com
bepagent3.example.com
rpa1.example.com
rpa2.example.com
mssql.example.com

# For single server setup

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
ct.example.com
ocr.example.com
bi.example.com
bepagent1.example.com
bepagent2.example.com
bepagent3.example.com
rpa.example.com
mssql.example.com

server.key

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-----

    and 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 Root certification authority (CA) bundle file. It must meet the following requirements:

  • The certificate must be in the PEM format.
  • server.crt must be signed by ca.crt.
  • The certificate must include only the Root certificate, without any intermediate ones.
  • 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 the ca.crt bundle must sign server.crt.
← DNS namesPorts →