Breadcrumbs

Create Client and Server Certificates

This topic provides information about creating LogRhythm client and server certificates, SQL Server certificates, and associated certificate formats required by LogRhythm components.

Certificate Requirements

Before generating certificates, review the following requirements.

Subject Name Requirements

  • For SQL Server server certificates, the Subject Name must be the Fully Qualified Domain Name (FQDN) of the host machine.

  • SQL Server certificates do not support IP addresses as the Subject Name.

  • For LogRhythm client and server certificates, the Subject Name can be either:

    • The FQDN of the host machine, or

    • The IP address of the host machine.

For all certificates, specify the Subject Name using the format:

CN=<FQDN_OR_IP>

Examples:

CN=pm.company.local
CN=10.10.10.50

Ensure there are no spaces between CN, =, and the Subject value. For example, use CN=pm.company.local, not CN = pm.company.local.

Root CA Trust Requirements

The client and server certificates must trust the certificate authority that issued them.

Ensure that:

  • The issuing Root CA certificate is present in the Trusted Root Certification Authorities certificate store.

  • Only the public certificate of the Root CA is imported into the Trusted Root Certification Authorities store.

  • The private key of the certificate authority must not be imported into the Trusted Root Certification Authorities store.

Subject Alternative Name (SAN) Requirements

If you require the LogRhythm Web Console to be recognized as a trusted HTTPS connection and avoid browser warnings such as "Accept Risk and Continue", the certificate should contain appropriate Subject Alternative Name (SAN) entries.

Modern browsers validate certificates using SAN values rather than the Subject Name alone.

Include SAN entries for any hostname, FQDN, DNS alias, or IP address that users may use when accessing the URL.

Examples:

https://pm.company.local
https://lrweb.company.local
https://10.10.10.50

When to Configure SAN Entries

Update the OpenSSL configuration before generating the Certificate Signing Request (CSR) if:

  • Users will access the system using a hostname.

  • Users will access the system using an FQDN.

  • Users will access the system using a DNS alias.

  • Users will access the system using an IP address.

  • Multiple access methods may be used.

Example SAN Configuration

The following example demonstrates a typical SAN configuration in openssl.cfg:

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
commonName = pm.company.local

[ v3_req ]
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = pm
DNS.2 = pm.company.local
DNS.3 = lrweb.company.local
IP.1  = 10.10.10.50

TrueIdentity Certificate Requirements

If the LogRhythm TrueIdentity Sync Client is installed on a remote host, custom or self-signed certificates must be generated and trusted on the Platform Manager before continuing with the configuration. If you are using the self-signed certificates located in C:\Program Files\LogRhythm\LogRhythm Common\LogRhythm API Gateway\tls, follow instructions to trust the certificates.

It is recommended that you create custom certificates.

Certificate Creation Workflow

The examples below demonstrate a self-signed OpenSSL workflow performed from a Windows command prompt.

This workflow generates, in the following order:

  1. Private Key

  2. Certificate Signing Request (CSR)

  3. Self-signed Certificate

  4. Personal Information Exchange (PFX)

Many production environments instead submit the generated CSR to an internal or external Certificate Authority (CA) for signing.

Using a Certificate Authority (CA)

If your organisation uses an internal or external Certificate Authority:

  1. Generate the private key and CSR using the instructions in this document.

  2. Submit the CSR to the Certificate Authority.

  3. Obtain the signed certificate and any required intermediate certificates.

  4. Skip the self-signing step.

  5. Use the conversion and export steps below as required.

If a valid CA-issued certificate already exists, only the certificate export or conversion steps may be required.

Generate Certificates Using OpenSSL

  1. Log on to the machine where the LogRhythm Platform Manager is installed.

  2. Navigate to:

C:\Program Files\LogRhythm\LogRhythm Infrastructure Installer\ssl

  1. Copy openssl.cfg into this directory.

  2. Modify openssl.cfg if SAN entries are required.

  3. Open a command prompt from this location.

Complete Example openssl.cfg

The following example provides a complete configuration including Common Name, SAN entries, and certificate extensions:

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req

[ dn ]
CN = pm.company.local

[ v3_req ]
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = pm
DNS.2 = pm.company.local
DNS.3 = lrweb.company.local
IP.1  = 10.10.10.50

Certificate Creation and Conversion Workflow

This workflow outlines the process required to create and convert certificates in detail.

  1. Configure openssl.cfg as required for your environment.

At a minimum, verify:

  • Common Name (CN)

  • DNS Subject Alternative Names (SANs)

  • IP Subject Alternative Names (SANs)

  • Certificate extensions

  1. Generate the Private Key and Certificate Signing Request (CSR) by running the following command:

openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -sha256 -keyout privateKey.key -config openssl.cfg

This command outputs the CSR.csr and the unencrypted privateKey.key.

  1. (Optional.) If using an internal or external Certificate Authority (CA):

    1. Submit CSR.csr to the CA.

    2. Obtain the signed certificate from the CA.

    3. Skip step 4 and continue with the certificate conversion/export steps as required.
      If creating a self-signed certificate, continue to step 4.

  2. Generate a public certificate from the CSR and private key by running the following command:

openssl x509 -req -days 365 -in CSR.csr -signkey privateKey.key -out LogRhythmSSL.crt -extensions v3_req -extfile openssl.cfg

This command outputs the LogRhythmSSL.crt.

This step is only required when generating a self-signed certificate. If a Certificate Authority will sign the CSR, this step is not required.

  1. Combine the public certificate and private key into a Personal Information Exchange (PFX) file by running the following command:

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in LogRhythmSSL.crt

This command outputs the certificate.pfx.

You will be prompted to enter an export password. Record this password as it will be required when importing the PFX file.

  1. If you need to extract the certificates from a PFX file:

    1. Export the private key by running the following command:

      openssl pkcs12 -in <certname>.pfx -nocerts -out privateKey.key -nodes

    2. Export the public certificate by running the following command:

      openssl pkcs12 -in <certname>.pfx -nokeys -out LogRhythmSSL.crt

  2. (Optional.) If the private key was generated with encryption or imported from an external source and the application requires an unencrypted private key, run the following command:

openssl rsa -in privateKey.key -out LogRhythmSSL.pem

This command outputs the LogRhythmSSL.pem.

This step is not required if you followed step 2, which generates an unencrypted private key by default (using the -nodes flag).

  1. (Optional.) Convert a CA-Supplied P7B Certificate, which is provided by some certificate authorities and is unreadable in most text editors, by running the following commands:

openssl pkcs7 -inform PEM -print_certs –in <pkcs7_certname>.p7b -out LogRhythmSSL.crt
openssl pkcs7 -inform DER -print_certs –in <pkcs7_certname>.p7b -out LogRhythmSSL.crt

This command outputs the LogRhythmSSL.crt.

  1. Validate the certificate details by running the following commands:

openssl rsa -noout -modulus -in privateKey.key | openssl md5
openssl x509 -noout -modulus -in LogRhythmSSL.crt | openssl md5
openssl x509 -in LogRhythmSSL.crt -noout -text | grep -A1 "Subject Alternative Name"

  1. Compare the MD5 values returned by the commands in step 9.
    It is expected that:

    1. Both hashes are identical.

    2. Matching hashes confirm that the certificate and private key belong to the same certificate pair.

    3. The output displays all DNS names and IP addresses configured in the [ alt_names ] section of openssl.cfg.

  2. Ensure the issuing Root CA certificate is present in the Trusted Root Certification Authorities store:

    1. Import only the Root CA public certificate.

    2. Do not import the Root CA private key into the Trusted Root Certification Authorities store.