Domain name and TLS certificates

Domain name requirements

To create a unique FQDN, ensure that a Domain Name System (DNS) server is configured and available with one of the following types of record:

• An A record that points to the IP address of the cluster.
• A CNAME record that points to the Red Hat OpenShift Container Platform cluster hostname.

dig <FQDN>

Certificate requirements

The TLS certificates must adhere to the following requirements:

• Always use a TLS certificate from a trusted CA for your production systems.
• The TLS certificate must be an RSA certificate with a minimum of 2048 bits, or a P-256 ECDSA certificate no greater than 256 bits with PKCS1 encoding.
• The TLS certificate must match the QRadar Suite Software domain and must specify the domain in the Subject Alternative Name (subjectAltName field).
• The TLS certificate and certificate authorities (CAs) must use a hash algorithm from the SHA-2 family.
• The TLS certificate must have a timespan that does not exceed 398 days.
• The TLS server certificate must contain an ExtendedKeyUsage (EKU) extension that contains the id-kp-serverAuth object identifier (OID).

If you use your own root CA for internal systems, it can have a time span that exceeds 398 days. This method can be useful for nonproduction environments. However, any system that is connected to the internet generates warnings if the server certificate is not issued by a well-known root authority that is recognized in browsers by default.

If you are using a certificate for QRadar Suite Software that is also a valid certificate for the IBM foundational services domain, you must use the HTTP/1.1 protocol. For more information about using the HTTP/1.1 protocol, see Enforcing the HTTP/1.1 protocol.

Wildcard certificates

You can use wildcard certificates for QRadar Suite Software.

When the QRadar Suite Software domain and the foundational services domain are subdomains of the same base domain and a wildcard certificate is used, the HTTP/2 connections between the client browser and the QRadar Suite Software domain are disabled, and the HTTP/1.1 protocol is enforced. For example, HTTP/1.1 is enforced under the following conditions:

• The QRadar Suite Software domain is cp4s.example.com
• The foundational services domain is cp-console.example.com
• The TLS certificate Subject Alternative Name (SAN) is set to DNS: *.example.com or *.apps.example.com

To validate that the SAN is correct, log in to your cluster and type the following command.

oc get route console -n openshift-console -o jsonpath="{.spec.host}" | sed -e 's/^[^\.]*/cp4s/' && echo

If the HTTP/1.1 protocol is not being enforced, see Enforcing the HTTP/1.1 protocol.

Creating your own CA and generating a TLS certificate with OpenSSL

For installation, QRadar Suite Software requires a server private key and server certificate that use keys that are signed by a certificate authority (CA).

An extra authority certificate is required if the provided server keys are signed by a nontrusted authority.

The result of using this example is that ca.key and ca.crt files are generated, containing the key and certificate for the CA.

To generate the server certificates, you can use the following example. The ca.key and ca.crt files can contain the key and certificate of the signing CA that you generated from the previous example, or your own key model. The DOMAIN environment variable is the name of domain for which the certificate is generated. For wildcard certificates, the value must start with *.

1. Create the OpenSSL configuration.
   1. Create the DOMAIN environment variable by typing the following command.

      export DOMAIN="<domain_name>"

   2. Create the COMMONNAME environment variable by typing one of the following commands.

      If your domain name is fewer than 64 characters, type the following command.

      export COMMONNAME=$DOMAIN

      If your domain name is greater than 64 characters, type the following command where <common_name> is a meaningful name, such as the first part of your domain name.

      export COMMONNAME=<common_name>

   3. Create the OpenSSL configuration by typing the following command.

      cat > openssl.cfg <<EOF
      [req]
      req_extensions = req_ext
      x509_extensions = usr_cert
      distinguished_name = req_name
      [ req_name ]
      commonName = $COMMONNAME
      [ usr_cert ]
      basicConstraints=CA:FALSE
      nsCertType = server
      keyUsage = nonRepudiation, digitalSignature, keyEncipherment
      extendedKeyUsage = serverAuth
      subjectKeyIdentifier = hash 
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = DNS:$DOMAIN
      [ req_ext ]
      subjectAltName = DNS:$DOMAIN
      EOF

2. Generate the certificate.
   1. Create the subj environment variable by typing the following command.

      export subj="/CN=$COMMONNAME"

   2. Generate the TLS key by typing the following command.

      openssl req -nodes -newkey rsa:2048 -keyout tls.key -outform PEM \
         -out tls.csr -subj "$subj" -config openssl.cfg

   3. Generate the TLS certificate in a temporary file by typing the following command.

      openssl x509 -req -sha256 -in tls.csr \
         -out tls.crt.tmp \
         -CA ca.crt -CAkey ca.key \
         -CAcreateserial -CAserial ca.serial \
         -days 398 -extensions usr_cert -extfile openssl.cfg

   4. Concatenate the TLS certificate and CA certificate into a single file by typing the following command.

      cat tls.crt.tmp ca.crt > tls.crt

   The result of using this example is that tls.key and tls.crt files are generated, containing the server key and certificate for the domain. The following certificates and key are generated by the example: tls.crt, tls.key, ca.crt. Sequentially, these certificates map to the following installation parameters: domainCertificatePath, domainCertificateKeyPath, customCaFilePath.

TLS Certificate parameters for installation

Use the TLS certificate information to complete the appropriate parameter values during installation.

Certificate replacement

If you need to replace the TLS certificate that you are using for QRadar Suite Software and it is not the same certificate that you are using for your Red Hat OpenShift Container Platform cluster, see Updating your QRadar Suite Software TLS certificates.

If you need to replace the TLS certificate that you are using for QRadar Suite Software and it is the same certificate that you are using for your Red Hat OpenShift Container Platform cluster, see Synchronizing QRadar Suite Software Certificates with the cluster certificate.