IBM Support

QRadar: Custom SSL certificate troubleshooting

Troubleshooting


Problem

Administrators who install custom SSL certificates on the QRadar Console can use this article to troubleshoot and verify common certificate issues.

Symptom

The Custom SSL Certificate not verifying correctly can cause user interface outages, communication issues between appliances, or issues where applications cannot communicate by using the API.

Diagnosing The Problem

Log in to the QRadar Console and at the SSH command-line run:
openssl verify -CAfile /etc/pki/tls/cert.pem /etc/httpd/conf/certs/cert.cert

Resolving The Problem

Reverting Custom SSL Certifications to Default QRadar Self-Signed Certificates
 
If you are having issues with a Custom SSL Certificate, you can revert to the Default QRadar Self-Signed certificate to use the steps provided to resolve your issues.

Note: As an option, you can revert to the Default QRadar Self-Signed certificate as you investigate the issue, and after resolved you can revert to the Customer SSL Certificates.

See the document: Revert to using a self-signed certificate
If you choose not to revert to the Default QRadar Self-Signed certificate, continue with these steps.

Read SSL certificate

From the SSH command line, type:

openssl x509 -in /etc/httpd/conf/certs/cert.cert -text -noout
Note: All the certificate information is displayed.
    

Unable to Get Issuer Certificate

  1.  From the SSH command-line run:
    openssl verify -CAfile /etc/pki/tls/cert.pem /etc/httpd/conf/certs/cert.cert

    Output if there is a missing member of the Chain:
    /etc/httpd/conf/certs/cert.cert
    /etc/httpd/conf/certs/cert.cert: DC = <info>, DC = <info>, CN = <Subject of the previous member of the certificate chain>error 20 at 1 depth lookup:unable to get issuer certificate
  2. Review the directory by running the command:
    ls -l /etc/pki/ca-trust/source/anchors/

    If the CA's root certificate or intermediate certificate (if applicable) is not present, then copy the CA's root certificate and intermediate certificate (if applicable) provided by your certificate authority to the /etc/pki/ca-trust/source/anchors directory.

    Note: The certificate must have a .cert, .crt, .pem, or .der file extension.
     
  3. (Optional). If you are using an internal CA, you must update the CA trust by running the command with the SSH command line:
    update-ca-trust
  4. If the CA's root certificate and intermediate certificate (if applicable) is not present.
    If you do not have these files, you must contact your certificate authority to provide the files and upload them to the /etc/pki/ca-trust/source/anchors directory.
     
  5. Confirm the certificate is now verifying correctly by running the command:
    openssl verify -CAfile /etc/pki/tls/cert.pem /etc/httpd/conf/certs/cert.cert

    The output of the command when the certificate verifies correctly:
    /etc/httpd/conf/certs/cert.cert: OK
  6.  Once the certificate verifies by using the openssl, restart the docker service on the console, or the App Host if one is attached:
    systemctl restart docker
  7. Extract the certificate
    1. To extract a PCKS7 certificate:
      1. Navigate to the folder where the pkcs7 resides.
      2. To extract the certificate, run the command:
        openssl pkcs7 -in certificate.p7b -inform PEM -print_certs -outform PEM -out /etc/pki/ca-trust/source/anchors/chain_certificate.pem
      3. Copy the certificate to a safe location.
    2. To Extract a PCKS12 certificate:
      1. Navigate to the folder where the .pfx certificate file resides.
      2. To extract the certificate, run the command:
        openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out /etc/pki/ca-trust/source/anchors/certificate.crt
      3. Copy the certificate to a safe location.

    

Invalid Subject within SSL certificate

  1. Run the command:
    /opt/qradar/support/recon ps

    Output if there is an invalid subject within the SSL certificate:
    Unable to communicate with API. Received error: An API error occurred. The API returned the error: Get https://<Console FQDN>/api/gui_app_framework/applications: x509: certificate is valid for <Subject within SSL certificate and alternate names (if applicable)> not <Console FQDN>
  2. Confirm the Console FQDN:
    openssl x509 -in /etc/httpd/conf/certs/cert.cert -text -noout | grep -i cn | grep Subject

    The output displays the subject that verifies the certificate:
    Subject: CN=<FQDN the certificate verifies>
  3. Confirm the FQDN of the Console:
    /opt/qradar/bin/myver -vh
    Or
     
    grep -i fqdn /opt/qradar/conf/nva.conf

    Output showing the Console FQDN:
    CONSOLE_FQDN=<Console FQDN>
  4. Resolving FQDN and Subject inconsistency
    1. Contact your certificate authority (Recommended)
      We recommend that you contact your certificate authority and request a new certificate with the "Subject: CN" that corresponds to the Console FQDN. You must then replace the current invalid SSL certificate with the newly acquired correct SSL certificate.

      See the document outlining the procedure: Installing a new SSL certificate
       
    2. Create a Multi-Domain (SAN) SSL certificate
      If you are required to access the Console from an alternate Domain, then you can create a SAN SSL certificate.

      Note: Multi-Domain SSL certificates are only applicable for Public Domains if you are using a public certificate authority, a Public certificate authority cannot sign a nonpublic Domain. For example, .local

      See the document that outlines how to Multi-Domain (SAN) SSL Certificate: Creating a multi-domain (SAN) SSL certificate signing request
       
    3. Change console FQDN to correspond to the SSL certificate
      Changing the FQDN requires running the qchange_netsetup at the remote console command line.

      Note:  To run qchange_netsetup, you need to remove all Managed Hosts from the deployment. Before the administrator runs the qchange_netsetup command, they also have to uninstall High Availability from the Console, or any Managed Hosts.

      See the document outlining the prerequisites for running the qchange_netsetup command:
      Changing the network settings in an all-in-one system

    

Expired Certificate

  1. From the SSH command-line run:
    openssl verify -CAfile /etc/pki/tls/cert.pem /etc/httpd/conf/certs/cert.cert

    Example Output:
    /etc/httpd/conf/certs/cert.cert: C = <info>, O = <info>, CN = <Subject of the previous member of the chain>
    error 10 at 0 depth lookup:certificate has expired
  2. Confirm the expiration of the Certificate
    From the SSH command-line run:
    openssl x509 -in /etc/httpd/conf/certs/cert.cert -text -noout | grep -A2 Validity

    Example Output:
    Validity
          Not Before: <Certificate issue date>
          Not After: <Certificate expiration date>

    Note: If you installed an Intermediate Certificate, you need to confirm the expiration of this file also.
     
  3. Resolution for an expired certificate
    You need to contact your certificate authority and request a new Certificate Bundle. Then, install the new certificate chain.

    See the document to replace an SSL certificate: Installing a new SSL certificate
  4. To test the validity of the certificates, use the command:
    /opt/qradar/ca/bin/verify-qradar-ca.sh --test
    Verify root CA has been created properly ... YES
    Verify intermediate CA has been created properly ... YES
    Verify appropriate CA and CRL is presented for download ... YES
    Verify the CA setup state is completed ... YES
    
    Final Result: 4 tests with 4 success and 0 failed
    
    
    

Document Location

Worldwide

[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwsyAAA","label":"Admin Tasks"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Version(s)"}]

Document Information

Modified date:
23 January 2023

UID

ibm16221256