Setting up certificate-based authentication on QRadar

In TLS over TCP communication between IBM® Disconnected Log Collector and IBM QRadar®, certificate-based communication is used to establish a chain of trust in which hardware and software is validated from the end entity to the root certificate.

Before you begin

This setup is completed by IBM QRadar on Cloud DevOps team and is completed only for the first Disconnected Log Collector (DLC). Adding additional DLCs do not require a support ticket so long as you continue to use the same CA.

Procedure

  1. If you're using your own truststore, type the following commands to add the client certificate's CA and the intermediate CA into your own truststore:
    keytool -import -alias client_root_ca -file client_root_ca.crt -keystore clientca
    
    keytool -import -alias client_int_ca -file client_int_ca.crt -keystore clientca
    
    Important:
    • The client_root_ca.crt file must be in X.509 format.
    • Run the second command only if your certificate is signed by an intermediate CA.
  2. To configure the server's certificate signing request (CSR), create a text file with this information:
    [ default ]
    # Change the following line to include the FQDN and IP address of the QRadar console or host
    SAN = DNS:<ec.example.com>,IP:<IP_address>
    [ req ]
    default_bits = 2048                        # RSA key size; change to 4096 if required by your
    organization
    encrypt_key = no                           # Protect private key
    default_md = sha256                        # MD to use
    utf8 = yes                                 # Input is UTF-8
    string_mask = utf8only                     # Emit UTF-8 strings
    prompt = no                                # Prompt for DN
    distinguished_name = server_dn             # DN template
    req_extensions = server_reqext             # Desired extensions
    [ server_dn ]
    organizationName = <your_organization_name>
    organizationalUnitName = <your_organizational_unit_name>
    commonName = <common_name>                 # Should match a listed SAN
    [ server_reqext ]
    keyUsage = critical,digitalSignature,keyEncipherment
    extendedKeyUsage = serverAuth,clientAuth
    subjectKeyIdentifier = hash
    subjectAltName = $ENV::SAN
  3. Save the text file as /tmp/tls-server.conf or in your preferred location.
  4. Generate a server certificate signing request (CSR) by typing the following command:
    openssl req -new -config /tmp/tls-server.conf -out /tmp/tls-server.csr -keyout /tmp/tlsserver.key

    A server CSR file is saved in /tmp/tls-server.csr, and a private key file is saved in /tmp/tls-server.key.

  5. Submit the CSR to your internal or commercial certificate authority for signing, according to their instructions.

    The procedure might involve opening the CSR file and copying a block of encoded text that is contained between BEGIN and END markers.

  6. Ensure that the client certificate is in PEM (Base64 ASCII) format. If the certificate is in DER (binary) format, convert it to PEM format by typing the following command:
    openssl x509 -inform der -in <certificate_file_name>.der -out <certificate_file_name>.pem
    Tip: A certificate's file extension does not necessarily indicate the encoding method that is used. For example, a certificate with a .cer extension might have Base-64 or DER encoding. Typically, you choose the encoding method during the certificate request procedure. Search the internet for information about OpenSSL commands that convert certificates from one format to another.
    The PEM file contains a block of encoded text that is contained between the BEGIN and END markers.
  7. If your CA uses an intermediate CA to sign certificates, ensure that the intermediate CA certificate is in PEM (Base64 ASCII) format. If the certificate is in DER (binary) format, convert it to PEM format (see the previous step). Then, append the intermediate CA certificate to the signed server certificate by typing the following command:
    cat <intermediate_ca_file_name>.pem >> <signed_server_certificate_file_name>.pem
  8. If the store server certificate that you received is not in PKCS#12 format, such as Distinguished Encoding Rules (DER), convert the client certificate to PKCS#12 format. Type the following command, and choose a secure password when prompted:
    openssl pkcs12 -inkey /tmp/tlsserver.key -in <signed_server_certificate_file_name>.pem -export -out dlc-server.pfx
    A generated personal exchange format (PFX) file is saved as /opt/ibm/si/services/dlc/keystore/dlc-client.pfx. The required PFX information is stored in the /opt/ibm/si/services/dlc/conf/config.json file.
  9. Choose a secure password when prompted.
  10. Copy the server certificate to the QRadar computer in the /opt/qradar/conf/key_stores directory. If the /key_stores folder doesn't exist, create it.
  11. In the QRadar on Cloud Self Serve app, update the Allow List with the egress IP address of the DLC.
  12. Open a Customer Support ticket and do the following:
    • Request a TLS syslog certificate. Certificates that are provided by QRadar on Cloud are signed by a Certificate Authority.
    • Attach the rootCA.crt in pem format.
  13. The IBM QRadar on Cloud DevOps team updates the ticket with the following information:
    • Key Store File Name
    • Key Store File Password
    • Trust Store File Path
    • Trust Store Password

Results

You can configure the Disconnected Log Collector log source on QRadar by using the dlc-server.pfx file that you created.

What to do next

Setting up TLS over TCP communication with QRadar