Replacing SSL Certificates in JSA Products
By default, JSA is configured with a self-signed Security Sockets Layer certificate. When you use a self-signed certificate to access the web, you're prompted with a warning message that the certificate is unrecognized. You can replace this SSL certificate with either an updated self-signed certificate, an internal certificate authority (CA) signed, or a public CA signed certificate.
SSL Certificates Overview
Secure Sockets Layer (SSL) is a security protocol that provides communication privacy. With SSL, client/server applications can communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.
SSL is an industry standard and is used by websites to protect online transactions. To generate an SSL link, a web server requires an SSL certificate. SSL certificates are issued by software or trusted third-party certifying authorities.
Browsers and operating systems include a preinstalled list of trusted certificates, which are installed in the Trusted Root Certification Authorities store. JSA products trust any certificate that is signed by a trusted root CA.
Table 1: JSA Supported Certificates
A self-signed certificate provides basic security, enabling data encryption between the user and the application. Because self-signed certificates cannot be authenticated by any existing known root certificate authorities, users are warned about this unknown certificate and must accept it to proceed.
Internal CA signed
Organizations that have their own internal root CA can create a certificate by using that internal CA. This certificate is supported by JSA, and the internal root CA is also imported into the JSA environment.
Public CA / Intermediate CA signed
Certificates that are signed by known public CAs and intermediate certificates are supported by JSA. Public signed certificates can be used directly in JSA, and certificates that are signed with Intermediate CA are installed by using both the signed certificate and the intermediate certificate to provide valid certificate functions.
Note: An intermediate certificate is commonly used by organizations that create multiple SSL keys in their environment, and want to have them signed by a known/commercial certificate vendor. When they use the intermediate key, they can then create sub-keys from this intermediate key. When this configuration is used, JSA must be configured with both the intermediate certificate and the host SSL certificate so that connections to the host can verify the full certificate path.
SSL Connections Between JSA Components
To establish all internal SSL connections between components, JSA uses the web server certificate that is preinstalled on the JSA Console. When the preinstalled certificate is replaced, the certificate installation process copies the certificate to all managed hosts in the deployment.
All trusted certificates for JSA must meet the following requirements:
The certificate must be an X.509 certificate and have PEM base64 encoding.
The certificate must have a .cert, .crt, .pem, or .der file extension.
Keystore files that contain certificates must have the .truststore file extension.
The certificate file must be stored in the /opt/qradar/conf/trusted_certificates directory.
If the SSL key is configured with a password, it must be manually entered each time that the service is restarted. With this configuration, the web UI service is unavailable until the password is entered, such as during a JSA patch installation, HA failover, or system restart. In this instance, users can't log in and JSA managed hosts can't retrieve configuration updates or report log source, rule and data storage status messages until the web service is available.
Creating an SSL Certificate Request with 1024-bit and 2048-bit RSA Keys
- Use an SSH client to log in JSA console.
- Generate a private key file by using one of the following
openssl genrsa -out qradar.key 2048
Do not use the private encryption options, because they can cause compatibility issues. The qradar.key file is created in the current directory. Keep this file to use when you install the certificate.
- Generate the certificate signing request (CSR) file. The
qradar.csr file is used to create the SSL Certificate, with an internal
CA or commercial certificate authorities. Run the following command,
and provide necessary information as prompted:
openssl req -new -key qradar.key -out qradar.csr
Provide the following information prompted in the command-line: [root@qradar ~]# openssl genrsa -out qradar.key 2048 Generating RSA private key, 2048 bit long modulus ........................................+++ ..........................+++ e is 65537 (0x10001) [root@bluecar ~]# openssl req -new -key qradar.key -out qradar.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ’.’, the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) :MyState Locality Name (eg, city) [Default City]:MyCity Organization Name (eg, company) [Default Company Ltd]:MyCompany Organizational Unit Name (eg, section) :MyCompanyOrg Common Name (eg, your name or your server's hostname) :qradar.mycompany.com Email Address :email@example.com Please enter the following ’extra’ attributes to be sent with your certificate request A challenge password : An optional company name : [root@bluecar ~]#
- If you want to verify the information in the CSR before
you send it, you can type the following command:
openssl req -noout -text -in qradar.csr
If incorrect information was entered, run the OpenSSL command again to re-create the CSR file.
- Use the Secure File Transfer Protocol or another program to securely copy the CSR file to your computer.
- Submit the CSR to your internal or commercial certificate authority for signing according to their instructions.
The CSR is identified as a certificate in Apache format.
Certificates signed by an Internal Certificate Authority
If the certificate is issued by an internal certificate authority and not a commercial certificate provider, JSA must be updated to include the internal root certificate into the local certificate store for proper certificate validation. Root verification certificates are automatically included with the operating system.
To update the trust anchors root certificate store in RedHat:
- Copy the CA's root certificate to /etc/pki/ca-trust/source/anchors/.
Run the following command at the SSH command line:
Installing a New SSL Certificate on the JSA Console
You must have the following:
The newly signed certificate from either your internal CA, or a public one.
The qradar.key private key to generate the CSR file.
An intermediate certificate, if used by your certificate provider.
If an intermediate certificate is used, run the "install-ssl-cert.sh" command with the -i flag to install both the new certificate and the intermediate certificate. When used, it prompts for 3 file paths:
- Use SSH to log in to your JSA console as the root user.
- Install the certificate by entering the following command:
[root@qavm215 ~]# /opt/qradar/bin/install-ssl-cert.sh Path to Public Key File (SSLCertificateFile): /root/new.certs/cert.cert Path to Private Key File (SSLCertificateKeyFile): /root/new.certs/cert.key
You have specified the following:
SSLCertificateFile of /root/updated.certs/cert.cert Re-configure Apache now (includes restart of httpd) (Y/[N])? y Backing up current SSL configuration ... (OK) Installing user SSL certificate ... (OK) Reloading httpd configuration: - Restarting httpd service ... (OK) Restarting services: - Stopping hostcontext ... (OK) - Restarting Tomcat ... (OK) - Starting hostcontext ... (OK) Tue Sep 19 14:45:57 ADT 2017 [install-ssl-cert.sh] OK: Install SSL Cert Completed [root@qavm215 ~]#
- On the navigation menu (), click Admin to open the admin tab.
- Click Advanced >Deploy Full Configuration.
When you deploy the full configuration, JSA restarts all services. Data collection for events and flows stops until the deployment completes.
If you have issues with your certificate, such as an incorrect name or IP address, or if the expiration date passes, or you have a change of IP or host name on your console, you can choose to revert to a self-signed certificate.
To generate a self-signed certificate, follow these steps on the JSA Console:
- Back up the certificates that were installed previously
that are not working. Existing certificates are detected and reported
when you run certificate generation, causing the generation process
mkdir /root/backup.certs/ mv /etc/httpd/conf/certs/cert.* /root/backup.certs/
- Run the /opt/qradar/bin/install-ssl-cert.sh –generate
command to generate new certificates. This process is also used during
JSA installation to generate the initial SSL certificate.
[root@qavm215 certs]# /opt/qradar/bin/install-ssl-cert.sh --generate Generating self-signed SSL certificate ... (OK) Installing generated SSL certificate ... (OK) Tue Sep 19 14:00:42 ADT 2017 [install-ssl-cert.sh] OK: Generated SSL certificate installed successfully [root@qavm215 certs]#
- Move the newly generated certificates to a new directory.
Use the install-ssl-certs.sh script in Install mode to install and
distribute the new SSL certificates.
[root@qavm215 ~]# mkdir /root/updated.certs/ [root@qavm215 ~]# mv /etc/httpd/conf/certs/cert.* /root/updated.certs/ [root@qavm215 ~]# /opt/qradar/bin/install-ssl-cert.sh Path to Public Key File (SSLCertificateFile): /root/updated.certs/cert.cert Path to Private Key File (SSLCertificateKeyFile): /root/updated.certs/cert.key
You have specified the following:
SSLCertificateFile of /root/updated.certs/cert.cert SSLCertificateKeyFile of /root/updated.certs/cert.key Re-configure Apache now (includes restart of httpd) (Y/[N])? y Backing up current SSL configuration ... (OK) Installing user SSL certificate ... (OK) Reloading httpd configuration: - Restarting httpd service ... (OK) Restarting services: - Stopping hostcontext ... (OK) - Restarting Tomcat ... (OK) - Starting hostcontext ... (OK) Tue Sep 19 14:45:57 ADT 2017 [install-ssl-cert.sh] OK: Install SSL Cert Completed [root@qavm215 ~]#