Domain name and TLS certificates
You must provide a TLS certificate for the QRadar® Suite Software platform Fully Qualified Domain Name (FQDN).
The TLS certificate can be one of the following types of certificate:
- A certificate for a specific FQDN, for example, my.example.com
- A wildcard certificate, for example, *.example.com or
*.apps.example.comTip: The wildcard character must be at the same level as your QRadar Suite Software. For example, if your QRadar Suite Software is at cp4s.apps.example.com, your wildcard certificate must be for *.apps.example.com.
Domain name requirements
- IBM Cloud®
- Amazon Web Services (AWS)
- Microsoft Azure
- VMware
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.
- Create the SUBJ environment variable by typing the following command,
where <CA_subject> is the name of the CA for which
the certificate is
generated.
export SUBJ="<CA_subject>"
For example, if the CA is
/CN=MyCA
, type the following command.export SUBJ="/CN=MyCA"
- Create the openssl.cfg by typing the following command, where <common_name> is the FQDN or, if the FQDN exceeds 64
characters, is a meaningful name, such as the first part of your domain
name.
cat <<EOF > openssl.cfg [ req ] distinguished_name = req_distinguished_name [ req_distinguished_name ] commonName = <common_name> commonName_max = 64 [ v3_ca ] basicConstraints = critical,CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always EOF
- Generate the CA key by typing the following
command.
openssl genrsa -out ca.key 4096
- Generate the CA certificate by typing the following
command.
openssl req -x509 -new -nodes -key ca.key -sha256 -days 825 \ -config openssl.cfg -extensions v3_ca \ -subj "$SUBJ" -out ca.crt
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 *.
- Create the OpenSSL configuration.
- Create the DOMAIN environment variable by typing the following
command.
export DOMAIN="<domain_name>"
- 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>
- 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
- Create the DOMAIN environment variable by typing the following
command.
- Generate the certificate.
- Create the subj environment variable by typing the following
command.
export subj="/CN=$COMMONNAME"
- 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
- 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
- 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.
- Create the subj environment variable by typing the following
command.
TLS Certificate parameters for installation
Use the TLS certificate information to complete the appropriate parameter values during installation.
Parameter | Description |
---|---|
domainCertificatePath | The path of the TLS certificate associated with the QRadar Suite Software application domain. |
domainCertificateKeyPath | The path of the TLS key associated with the QRadar Suite Software application domain. |
customCaFilePath | The path of the custom TLS certificate associated with the QRadar Suite Software application domain. |
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.