Create certificates

Create certificates as part of installing PEG.

Prerequisites

You can create certificates by using one of two options.
In both cases, you will need the following:
  • Unique ID (UID): Each PEG VM you run must have a unique id. You can define the UID to be anything you want as long as it meets the following criteria:
    • Less than or equal to 18 characters in length
    • Contains only letters from a to z, numbers from 0 to 9 or hyphens
    • Must not begin or end with a hyphen
    • Must not contain consecutive hyphens
    • Tip: To easily create a UID, take the last 18 characters of a GUID generated from an online GUID generator.
  • The apex domain that you want to use for the PEG DNS names (for example, example.com)

Option 2 - Create your own keys and certificates

Learn how to create keys and certificates before you deploy PEG.

Keys and certificates must be in Base64 PEM format (called openssl or PKCS #8 for the key format in some systems). Create certificates according to Common Tasks - Creating the certificates. Keys must not be password protected. Also, ensure that your keys match the file names in the Key File Name column of, Common Tasks - Creating the certificates.

It is important to verify the certificate pasted into the terminal matches the source certificate, exactly. Some applications might append the file with a hidden character, during copying and pasting. To avoid any issues, the following steps offer assistance.

  • Verify file content: after pasting the content into the file, use a text editor (like nano, vim, or gedit) to check the file for any unwanted characters at the end.
  • Use echo with redirection: instead of directly pasting the content, use echo with redirection to create the file. This minimizes the risk of hidden characters.
  • Use scp to copy over the files from your local system to remote instance instead of copying these over.

Common Tasks - Creating the certificates

Learn how to create Base64 PEM certificates.

When you create the certificates, create six server Base64 PEM certificates (called openssl format in some systems), with domain names and file names mapped as follows, where the UID is provided to you by Process Discovery and the apex domain is your apex domain that you will use for PEG. Each certificate you create must just contain the leaf certificate and not the full chain.

Table 1. Mapping of domain names to certificate file names
Domain Cert file name Key file name (Required only if you created your own keys)
analytics-fiq-<UID>.<apex domain> analytics-cert.pem analytics-key.pem
proxy-fiq-<UID>.<apex domain> proxy-cert.pem proxy-key.pem
storage-fiq-<UID>.<apex domain> storage-cert.pem storage-key.pem
st-fiq-<UID>.<apex domain> st-cert.pem st-key.pem
dlp-fiq-<UID>.<apex domain> dlp-cert.pem dlp-key.pem
es-fiq-<UID>.<apex domain> es-cert.pem es-key.pem
klite-fiq-<UID>.<apex domain> klite-cert.pem klite-key.pem
Note: You can create one certificate with all of the SANs. You can also create just one key if you create keys if you want. However, you will still need to make sure there are seven copies of that certificate and seven copies of that key (if you created keys) named as indicated previously. Do not create a wildcard certificate.

Considerations

Review the following considerations for creating certificates for installing PEG:
  • Wildcard Certificates are Not Allowed: You cannot use wildcard certificates for PEG deployments. Each certificate must be individually created for each service with a specific domain name.
  • Certificates Are Not Globally Valid: Internal CA-generated certificates are not recognized as globally trusted by external systems, meaning they need to be manually trusted on all client devices or services.
  • Manual Validation of Certificates: Certificates need to be manually validated at each deployment stage to ensure they are correct and have not been corrupted or tampered with during transfer.
  • Manual Certificate Transfer: Certificates must be manually copied over to the virtual machines (VMs), which can lead to potential errors if done incorrectly or if files are altered during the copying process.
  • Ensure Valid Certificates on All Machines: It's essential to confirm that all certificates are valid and correctly installed on any machine that needs to access the services secured by these certificates.
  • No Automated Certificate Renewal: Since internal certificates lack integration with global CA systems, there is no automated renewal process. Administrators must manually track and renew certificates before they expire to prevent service disruptions.
  • Additional Configuration for Trust: Each client or system accessing the PEG services must be manually configured to trust the internal CA certificates, which might involve installing root certificates or adjusting security settings.
  • Risk of Human Error: The manual nature of certificate creation, validation, and distribution increases the likelihood of human error, such as incorrect file names, invalid configurations, or missing certificates.
  • Limited Revocation and Auditing: Internal CA setups might lack sophisticated revocation mechanisms (like Certificate Revocation Lists or OCSP), making it harder to revoke compromised or expired certificates and audit their usage effectively.
  • Difficulty in Scaling: Managing a large number of certificates manually across multiple Virtual Machines (VMs) and environments can become difficult as the system scales, requiring dedicated processes to ensure consistency.