Background on Encryption and Mutual Autentication

crescentwire · ‎2023-04-25

Written by Michael Ibarra, Security Engineer, Mid-Atlantic Region

March 7, 2023

Background on Encryption and Mutual Autentication

Because almost no computer exchanges data directly with another, data is almost always passed through some layer 3 (routing-capable) interface. Any devices along that path handle the data being transmitted, which presents risk to data integrity. It should go without saying that we want that data to be secure; that is, arriving in the same state as when it left, without any unauthorized tamperig. One common way to satisfy this requirement is using encryption.

Encrypting data so the sender and receiver can understand it (but others in the transmission path cannot) requires an agreed-upon method; this is known as public key cryptography. Suppose two computers, Host A and Host B, want to exchange data securely. Each computer will use two components to encrypt and decrypt communication between them:

Public key (used to encrypt)
Private key (used to decrypt)

Asymmetric Encryption

Host A's public key is shared with Host B, so Host B can use it to encrypt data. Host A receives encrypted data from Host B and uses its private key to decrypt it. (Host B also shares its private key with Host A, and the process is mirrored in the opposite direction.) This is called asymmetric encryption. Each computer uses a different public key, hence the name.

Symmetric Encryption

Host A still shares its public key with Host B, but instead of immediately sharing data and stopping there, Host B replies with a specific key both computers can use to decrypt each other's data. Instead of relying on a unique public key for encrypting data for each receiver, both computers share the same key. This is called symmetric encryption.

Mutual Authentication

Host A and Host B must trust each other completely to exchange data securely, but if this trust is compromised (e.g., through a man-in-the-middle attack), then even the best encryption methods cannot safeguard against a case of masquerading identity. Computers can verify each other’s identities by inspecting their certificate authority (CA)-signed certificates, which have inherent credibility through a trusted chain of CAs.

Computers holding a forged certificate, or one issued by a non-trusted CA, will be ignored when they try to communicate with others on a network.

Performing this identity validation in both directions is known as mutual TLS (mTLS) authentication.

Check Point Considerations

Log Exporter supports mTLS with the following stipulations:

Utilizes TLS 1.2 for mutual authentication.
Only mutual authentication is allowed.

NOTE: This document was written based on configuration tested with a Secure Management Server. If logs are stored on a dedicated log server, the configuration and steps should be adapted for that scenario.

The core requirements are:

CA certificate (PEM format), that signs both the client (log exporter instance on SMS) and server (syslog/destination log server).
Client certificate (P12 format) on the SMS where the log exporter instance runs.
SMS must be able to connect to the CA.
A third certificate (signed by the same CA) should also be installed on the syslog server to secure communication there as well.
- This validates the syslog server's identity to the SMS.

Implementation Steps (Certificate Generation)

The following sections offer three approaches for generating the required certificates:

Purchasing through a well-known, trusted certificate authority (CA) (e.g., Comodo, Digicert, Entrust, etc.)
Utilizing an existing internal CA within your organization
Establishing a new internal CA (cannot be the SMS or syslog destination server)

Each of these scenarios is covered in detail below.

External CA

This procedure requires three separate systems:

Trusted external CA (e.g., Comodo, Digicert, Entrust, etc.)
Security Management Server (SMS)
Destination log server (e.g., syslog)

Generate SMS Keys, Certificates

On the SMS (considered the client), generate a new private key for use by the log exporter instance.

cpopenssl genrsa -out client-sms-key.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
......+++++
..................................+++++
e is 65537 (0x010001)

Generate a new certificate signing request (CSR), using the newly generated private key. This command will prompt for several fields, including a password. Note that the Common Name field should only contain the internal CA's IP address.

cpopenssl req -new -key client-sms-key.pem -out client-sms-req.pem

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) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.100
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.

NOTE: When prompted, enter values as desired or enter . to indicate the field is empty. The only required value is Common Name.

Provide the client-sms-req.pem file to an external CA and wait for the resulting certificate to be generated. The resulting file, client-sms-cert.pem, will be a certificate with the SMS' public key embedded, signed with the private key of the external CA.
If the generated certificate is in P12 format, proceed to the next step. If it is not, use the CA-generated certificate file and private key to generate a P12 file. When prompted, enter the password used in step 2.

cpopenssl pkcs12 -inkey client-sms-key.pem -in client-sms-cert.pem -export \
-out client-sms-cert.p12

Enter Export Password:
Verifying - Enter Export Password:

NOTE: This command takes both the generated certificate (with an embedded public key) and the private key as inputs and generates a PKCS12 file. The resulting file contains the certificate, public key, and private key, and should be treated as a highly sensitive security asset.

Generate Destination Log Server Keys, Certificates

NOTE: syslog-ng is used in these steps but any log server supporting mTLS should be compatible. Refer to your vendor's log server documentation for guidance on adapting the following steps.

On the syslog server, generate a new private key.

openssl genrsa -out server-syslog-key.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
...............................+++++
.......................................................................+++++
e is 65537 (0x010001)

Next, generate a certificate signing request (CSR) using the newly generated private key. This command will prompt for several fields, including a password. Note that the Common Name field should only contain the internal CA's IP address.

openssl req -new -key server-syslog-key.pem -out server-syslog-req.pem

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) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.192
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.

NOTE: Refer to your destination log server's documentation for which fields to populate. Otherwise, when prompted, enter values as desired or enter . to indicate the field is empty.

Provide the server-syslog-req.pem file to an external CA and wait for the resulting certificate to be generated. The resulting file, server-syslog-cert.pem, will be a certificate with the syslog server's public key embedded, signed with the private key of the external CA.

Existing Internal CA

This procedure requires three separate systems:

Linux (recommended, using OpenSSL) or Windows-based internal CA
Security Management Server (SMS)
Destination log server (e.g., syslog)

Generate SMS Keys, Certificates

On the SMS (considered the client), generate a new private key for use by the log exporter instance.

cpopenssl genrsa -out client-sms-key.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
......+++++
..................................+++++
e is 65537 (0x010001)

Generate a new certificate signing request (CSR), using the newly generated private key. This command will prompt for several fields, including a password. Note that the Common Name field should only contain the internal CA's IP address.

cpopenssl req -new -key client-sms-key.pem -out client-sms-req.pem

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) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.100
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.

NOTE: When prompted, enter values as desired or enter . to indicate the field is empty. The only required value is Common Name.

Copy the CSR file to the internal CA server and sign the request with the CA's private key:

openssl x509 -req -in client-sms-req.pem -CA cacert.pem -CAkey cakey.pem /
-CAcreateserial -out client-sms-cert.pem -days 365 -sha256

NOTE: Modify the CA certificate and private key file values to match your environment's configuration.

Copy the client-sms-cert.pem file back to the SMS and convert it to a P12 file. When prompted, enter the password used in step 2.

cpopenssl pkcs12 -inkey client-sms-key.pem -in client-sms-cert.pem -export /
-out client-sms-cert.p12

Enter Export Password:
Verifying - Enter Export Password:

NOTE: This command takes both the generated certificate (with an embedded public key) and the private key as inputs and generates a PKCS12 file. The resulting file contains the certificate, public key, and private key, and should be treated as a highly sensitive security asset.

Generate Destination Log Server Keys, Certificates

NOTE: syslog-ng is used in these steps but any log server supporting mTLS should be compatible. Refer to your vendor's log server documentation for guidance on adapting the following steps.

On the syslog server, generate a new private key.

openssl genrsa -out server-syslog-key.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
...............................+++++
.......................................................................+++++
e is 65537 (0x010001)

Next, generate a certificate signing request (CSR) using the newly generated private key. This command will prompt for several fields, including a password. Note that the Common Name field should only contain the internal CA's IP address.

openssl req -new -key server-syslog-key.pem -out server-syslog-req.pem

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) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:10.5.1.192
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<redacted>
An optional company name []:.

NOTE: Refer to your destination log server's documentation for which fields to populate. Otherwise, when prompted, enter values as desired or enter . to indicate the field is empty.

Copy the CSR file to the internal CA server and sign the request with the CA's private key:

openssl x509 -req -in server-syslog-req.pem -CA cacert.pem -CAkey cakey.pem /
-CAcreateserial -out server-syslog-cert.pem -days 365 -sha256

NOTE: Modify the CA certificate and private key file values to match your environment's configuration.

Copy the server-syslog-cert.pem file back to the syslog server and store it in the appropriate identity certificates directory.

New Internal CA

Linux (recommended, using OpenSSL) or Windows-based internal CA
Security Management Server (SMS)
Destination log server (e.g., syslog)

Create and Configure Internal CA

NOTE: The following steps were adapted from syslog-ng Open Source Edition 3.16 - Mutual authentication using TLS.

The following steps assume a directory structure of /etc/ssl/openssl.cnf.

Create a new CA root directory:

mkdir /etc/ssl/CA

Create several other directories inside CA:

cd /etc/ssl/CA
mkdir certs crl newcerts private
touch serial index.txt

Copy openssl.cnf to this new directory:

cp /etc/ssl/openssl.cnf /openssl.cnf

Under the [ CA_default ] section of openssl.cnf, set the value of dir to .:

vi openssl.cnf

####################################################################
[ CA_default ]

dir             = .                     # Where everything is kept

Finally, generate a new private key for the CA and the resulting certificate:

openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 /
-config openssl.cnf

req - PKCS#10 certificate request and certificate generating command.
-new - Generates a new CSR, prompting for relevant values.
-x509 - Outputs a certificate.
-keyout - Specifies the path/filename for the private key.
-out - Specifies the final certificate path/filename.
-days - Used alongside -x509; sets duration of certificate's validity (default is 30 days).
-config - Specifies a file to read any other configuration from.

Generate SMS Keys, Certificates

Generate a new private key for the SMS (considered the client), along with a CSR:

openssl req -nodes -new -x509 -keyout client-sms-key.pem -out client-sms-/
req.pem -days 365 -config openssl.cnf

Sign the generated CSR with the SMS's private key:

openssl x509 -x509toreq -in client-sms-req.pem -signkey client-sms-key.pem /
-out tmp.pem

Finally, generate the SMS's certificate using the CSR and CA's private key (to sign it):

openssl ca -config openssl.cnf -policy policy_anything -out /
client-sms-cert.pem -infiles tmp.pem

Delete the tmp.pem file.

rm tmp.pem

Copy the client-sms-cert.pem file back to the SMS and convert it to a P12 file. When prompted, enter the password used in step 2.

cpopenssl pkcs12 -inkey client-sms-key.pem -in client-sms-cert.pem -export /
-out client-sms-cert.p12

Enter Export Password:
Verifying - Enter Export Password:

NOTE: This command takes both the generated certificate (with an embedded public key) and the private key as inputs and generates a PKCS12 file. The resulting file contains the certificate, public key, and private key, and should be treated as a highly sensitive security asset.

Generate Destination Log Server Keys, Certificates

Generate a new private key for the syslog server, along with a CSR:

openssl req -nodes -new -x509 -keyout server-syslog-key.pem -out /
server-syslog-req.pem -days 365 -config openssl.cnf

req - PKCS#10 certificate request and certificate generating command.
-nodes - Stores the private key in plain text without a passphrase (unencrypted).
-new - Generates a new CSR, prompting for relevant values.
-x509 - Outputs a certificate.
-keyout - Specifies the path/filename for the private key.
-out - Specifies the final certificate path/filename.
-days - Used alongside -x509; sets duration of certificate's validity (default is 30 days).
-config - Specifies a file to read any other configuration from.

Sign the generated CSR with the syslog server's private key:

openssl x509 -x509toreq -in server-syslog-req.pem -signkey /
server-syslog-key.pem -out tmp.pem

x509 - X.509 Certificate Data Management
-x509toreq - Outputs a CSR instead of a certificate
-in - Specifies the input filename (CSR in this case)
-signkey - Specifies the path/filename for the private key used to sign the certificate.
-keyout - Specifies the path/filename for the private key.
-out - Specifies the final certificate path/filename.

Finally, generate the syslog server's certificate using the CSR and CA's private key (to sign it):

openssl ca -config openssl.cnf -policy policy_anything -out /
server-syslog-cert.pem -infiles tmp.pem

ca - Certificate Authority (CA) Management.
-config - Specifies a file to read any other configuration from.
-policy - Specifies the CA policy to use (within openssl.cnf).
-out - Specifies the final certificate path/filename.
-infiles - Specifies the file(s) containing CSRs; should always be the last option in the command.
tmp.pem - The CSR, generated in the previous step.

Delete the tmp.pem file.

rm tmp.pem

Configuration Examples

Splunk (On-Prem)

NOTE: The following steps were validated on Ubuntu 22.04 with Splunk 9.0.4 and assume Splunk is installed and running under /opt. Adapt the steps depending on where your installation resides. As well, all configuration has been done within the context of a non-privileged user account named splunk.

Create a new directory under /opt/splunk/etc/app:

cd /opt/splunk/etc/apps
mkdir -p sms-tls/{certs,local}

Depending on the type of CA in use (internal, external, etc.), generate a new certificate for the Splunk server. Below are the steps for doing this on an existing internal CA (OpenSSL on Linux):

openssl genrsa -out server-splunk-key.pem 2048

openssl req -new -key server-splunk-key.pem -out server-splunk-req.pem

openssl x509 -req -in server-splunk-req.pem -CA cacert.pem -CAkey /
private/cakey.pem -CAcreateserial -out server-splunk-cert.pem -days 365 -sha256

NOTE: Regardless of process used, make sure the private key file is not encrypted. At least on Splunk 9.0.4 with OpenSSL 3.0.2, there exists a bug that prevents decryption of the private key.

Combine the server certificate and private key into a single file:

cat server-splunk-cert.pem server-splunk-key.pem >> /
server-splunk-cert-combined.pem

Copy this new file to the Splunk server, under /opt/splunk/etc/apps/sms-tls/certs. Also copy cacert.pem to the same directory.
Configure a new inputs.conf file under /opt/splunk/etc/apps/sms-tls/local with the following properties:

splunk@splunk-test:/opt/splunk/etc/apps/sms-tls/local$ nano inputs.conf

[SSL]
serverCert = /opt/splunk/etc/apps/sms-tls/certs/server-splunk-cert-combined.pem
sslVersions = tls,-tls1.0
requireClientCert = true

[tcp-ssl:6514]

Configure a new server.conf file with the following properties:

splunk@splunk-test:/opt/splunk/etc/apps/sms-tls/local$ nano server.conf

[sslConfig]
serverCert = /opt/splunk/etc/apps/sms-tls/certs/server-splunk-cert-combined.pem
sslRootCAPath = /opt/splunk/etc/apps/sms-tls/certs/cacert.pem
sslVerifyServerCert = true

With these configuration changes complete, the directory structure should resemble this:

splunk@splunk-test:/opt/splunk/etc/apps/sms-tls$ tree ./
./
├── certs
│   ├── cacert.pem
│   ├── server-splunk-cert-combined.pem
├── local
│   ├── inputs.conf
│   └── server.conf
└── metadata
    └── local.meta

Finally, restart Splunk with /opt/splunk/bin/splunk restart and proceed to configure Log Exporter on the SMS.

Configure SMS Log Exporter

Log in to the SMS (or the log server where Log Exporter will run) and enter Expert mode.
Configure the destination log server using the cp_log_export command:

cp_log_export add name splunk target-server 10.5.1.191 target-port 6514 /
protocol tcp format splunk

NOTE: All the arguments above are customizable; see the Reference section for guidance on syntax.

NOTE: Though you will be prompted, do not restart the Log Exporter service yet; proceed to configure TLS.

Create a new directory called tls for storing the CA and log exporter identity certificates:

mkdir $EXPORTERDIR/targets/splunk/tls

Copy the issuing CA's certificate (in this example, cacert.pem) and client-sms-cert.p12 from the certificate generation steps to this new directory.
Edit the XML configuration for the destination just added using VIM:

vi $EXPORTERDIR/targets/splunk/targetConfiguration.xml

Note the section nested under the <transport> tag:

<transport>
    <security></security>
    <!--clear/tls-->
    <!-- the following section is relevant only if <security> is tls -->
    <pem_ca_file></pem_ca_file>
    <p12_certificate_file></p12_certificate_file>
    <client_certificate_challenge_phrase></client_certificate_challenge_phrase>
</transport>

Modify the following lines to configure TLS:

<transport>
    <security>tls</security><!--clear/tls-->
    <!-- the following section is relevant only if <security> is tls -->
    <pem_ca_file>/opt/CPrt-R81.20/log_exporter/targets/splunk/tls/cacert.pem</pem_ca_file>
    <p12_certificate_file>/opt/CPrt-R81.20/log_exporter/targets/splunk/tls/client-sms-cert.p12</p12_certificate_file>
    <client_certificate_challenge_phrase>p@55w0rd</client_certificate_challenge_phrase>
</transport>

NOTE: The challenge phrase is replaced with $Encrypted$ after the Log Exporter service is restarted.

Save changes and quit VIM using :x. Verify the changes before proceeding:

cat $EXPORTERDIR/targets/splunk/targetConfiguration.xml

Finally, restart the Log Exporter service to activate the new log destination:

cp_log_export restart name splunk

Confirm operation using the following commands:

cp_log_export status
cp_log_export show

Finally, validate log delivery with this query on the main Splunk indexer:

index="main" 10.5.1.100

Log Exporter (Check Point SMS) logs:

Destination log server (Splunk) logs:

Packet capture (from Splunk’s perspective):

Syslog Server (On-Prem)

NOTE: These steps were validated on Ubuntu 22.04 using syslog-ng.

Configure Destination Log Server

NOTE: The following steps assume a directory structure of /etc/syslog-ng.

After installing syslog-ng, create several new directories within /etc/syslog-ng:

cd /etc/syslog-ng
mkdir cert.d ca.d

Copy the previously generated server certificate files to cert.d:

cp serverkey.pem cert.d/server-syslog-key.pem
cp servercert.pem cert.d/server-syslog-cert.pem

Retrieve the CA's certificate (external or internal) and copy it to ca.d:

cp cacert.pem ca.d/cacert.pem

Generate a hash value for the CA certificate:

openssl x509 -noout -hash -in ca.d/cacert.pem

root@syslog-ng:/etc/syslog-ng# openssl x509 -noout -hash -in ca.d/cacert.pem
9858a3e4

Add a new (soft) symbolic link to the CA certificate using the hash value generated. Be sure to include the .0 value as a suffix.

cd ca.d
ln -s cacert.pem 9858a3e4.0

Verify the new symbolic link:

root@syslog-ng:/etc/syslog-ng/ca.d# ls -l
total 4
lrwxrwxrwx 1 root root   10 Feb 23 11:18 9858a3e4.0 -> cacert.pem
-rw-r--r-- 1 root root 1204 Feb 23 11:11 cacert.pem

Edit syslog-ng.conf, adding the following lines:

# Place this under "Sources"
source sms_tls_source {
    network(ip(10.5.1.100) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/server-syslog-key.pem")
             cert-file("/etc/syslog-ng/cert.d/server-syslog-cert.pem")
             ca-dir("/etc/syslog-ng/ca.d"))
    ); };

log { source(sms_tls_source); destination(sms_tls_dest); };

# Place this under "Destinations"
destination sms_tls_dest { file("/var/log/syslog-ng/sms_tls_logs.log"); };

NOTE: The destination directory path must already exist. In this example, syslog-ng should be created with mkdir /var/log/syslog-ng.

NOTE: Modify ip(10.5.1.100) to match your SMS/log server's IP address.

Finally, restart the syslog-ng service:

systemctl restart syslog-ng

Configure SMS Log Exporter

Log in to the SMS (or the log server where Log Exporter will run) and enter Expert mode.
Configure the destination log server using the cp_log_export command:

cp_log_export add name syslog-ng target-server 10.5.1.193 target-port 6514 /
protocol tcp format syslog

NOTE: All the arguments above are customizable; see the Reference section for guidance on syntax.

NOTE: Though you will be prompted, do not restart the Log Exporter service yet; proceed to configure TLS.

Create a new directory called tls for storing the CA and log exporter identity certificates:

mkdir $EXPORTERDIR/targets/syslog-ng/tls

Copy the issuing CA's certificate (in this example, cacert.pem) and client-sms-cert.p12 from the certificate generation steps to this new directory.
Edit the XML configuration for the destination just added using VIM:

vi $EXPORTERDIR/targets/syslog-ng/targetConfiguration.xml

Note the section nested under the <transport> tag:

<transport>
    <security></security>
    <!--clear/tls-->
    <!-- the following section is relevant only if <security> is tls -->
    <pem_ca_file></pem_ca_file>
    <p12_certificate_file></p12_certificate_file>
    <client_certificate_challenge_phrase></client_certificate_challenge_phrase>
</transport>

Modify the following lines to configure TLS:

<transport>
    <security>tls</security>
    <!--clear/tls-->
    <!-- the following section is relevant only if <security> is tls -->
    <pem_ca_file>/opt/CPrt-R81.20/log_exporter/targets/syslog-ng/tls/cacert.pem</pem_ca_file>
    <p12_certificate_file>/opt/CPrt-R81.20/log_exporter/targets/syslog-ng/tls/client-sms-cert.p12</p12_certificate_file>
    <client_certificate_challenge_phrase>p@55w0rd</client_certificate_challenge_phrase>
</transport>

NOTE: The challenge phrase is replaced with $Encrypted$ after the Log Exporter service is restarted.

Save changes and quit VIM using :x. Verify the changes before proceeding:

cat $EXPORTERDIR/targets/rsyslog/targetConfiguration.xml

Finally, restart the Log Exporter service to activate the new log destination:

cp_log_export restart name syslog-ng

Confirm operation using the following commands:

cp_log_export status
cp_log_export show

Finally, validate log delivery by checking the relevant log file contents on the syslog server (in this example, /var/log/syslog-ng/sms_tls_logs.log).

Log Exporter (Check Point SMS) logs:

Destination log server (syslog-ng) logs:

Packet capture (from syslog-ng’s perspective):

Smart-1 Cloud

Log delivery using mTLS is supported, but Smart-1 Cloud must be treated as a client (source), requiring a signed certificate from a CA.

For the full set of configuration steps, refer to the section titled "Forwarding Events to SIEM" in the Smart-1 Cloud Admin Guide.

Validation

Validate a CSR:

openssl req -text -noout -verify -in csrfile.[pem|csr]

ica@ica:/etc/ssl/CA$ openssl req -text -noout -verify -in tmp.pem
Certificate request self-signature verify OK
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = US, O = CHKP-LAB, CN = 10.5.1.193
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    <omitted>
                Exponent: 65537 (0x10001)
        Attributes:
            (none)
            Requested Extensions:
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        <omitted>

Validate a private key:

openssl rsa -in keyfile.[pem|key] -check

ica@ica:/etc/ssl/CA$ sudo openssl rsa -in private/cakey.pem -check
[sudo] password for ica:
Enter pass phrase for private/cakey.pem:
RSA key ok
writing RSA key
-----BEGIN PRIVATE KEY-----
<omitted>
-----END PRIVATE KEY-----

ica@ica:/etc/ssl/CA$ sudo openssl rsa -in serverkey.pem -check
[sudo] password for ica:
RSA key ok
writing RSA key
-----BEGIN PRIVATE KEY-----
<omitted>
-----END PRIVATE KEY-----

NOTE: serverkey.pem was created with -nodes, so it's considered plaintext. No passphrase is required to view the contents.

Validate a certificate:

openssl x509 -in cert.[pem|crt] -text -noout

ica@ica:/etc/ssl/CA$ openssl x509 -in cacert.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:1c:17:aa:37:11:86:cd:9c:b2:db:1b:bb:82:35:55:9d:bc:86:71
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = CHKP-LAB, CN = 10.5.1.194
        Validity
            Not Before: Feb 23 01:26:19 2023 GMT
            Not After : Feb 23 01:26:19 2024 GMT
        Subject: C = US, O = CHKP-LAB, CN = 10.5.1.194
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    <omitted>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                56:70:48:23:2E:CD:D2:9E:87:F8:13:BF:0B:89:67:8D:64:8C:10:F1
            X509v3 Authority Key Identifier:
                56:70:48:23:2E:CD:D2:9E:87:F8:13:BF:0B:89:67:8D:64:8C:10:F1
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        <omitted>

ica@ica:/etc/ssl/CA$ openssl x509 -in servercert.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = CHKP-LAB, CN = 10.5.1.194
        Validity
            Not Before: Feb 23 01:37:50 2023 GMT
            Not After : Feb 23 01:37:50 2024 GMT
        Subject: C = US, O = CHKP-LAB, CN = 10.5.1.193
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    <omitted>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Subject Key Identifier:
                A2:55:4F:5E:D3:B7:8B:5C:C0:21:EF:4E:47:AA:A7:78:88:42:52:BD
            X509v3 Authority Key Identifier:
                56:70:48:23:2E:CD:D2:9E:87:F8:13:BF:0B:89:67:8D:64:8C:10:F1
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        <omitted>

Use the -dates operator to show the validity period:

$ openssl x509 -noout -dates -in ca.pem

notBefore=Jan 20 20:50:08 2023 GMT
notAfter=Aug 29 20:50:08 2028 GMT

Validate a PKCS12 file (format used by Check Point's Log Exporter for mTLS):

[Expert@ih-sms01:0]# cpopenssl pkcs12 -info -in log_exporter_source.p12
Enter Import Password: <redacted>
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
    localKeyID: 58 BF A1 58 B2 AB F7 B0 43 05 4E C0 12 18 BD C0 D3 83 59 88
subject=C = US, O = Customer ABC, CN = 10.5.1.100

issuer=C = US, O = Check Point Software Technologies Ltd, CN = 10.5.1.85

-----BEGIN CERTIFICATE-----
<omitted>
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
    localKeyID: 58 BF A1 58 B2 AB F7 B0 43 05 4E C0 12 18 BD C0 D3 83 59 88
Key Attributes: <No Attributes>
Enter PEM pass phrase: <redacted>
Verifying - Enter PEM pass phrase: <redacted>
-----BEGIN ENCRYPTED PRIVATE KEY-----
<omitted>
-----END ENCRYPTED PRIVATE KEY-----

NOTE: The command used on Check Point appliances is cpopenssl.

Reference

Syntax for cp_log_export command:

cp_log_export add name <Name> [domain-server {mds | all}] target-server /
<HostName or IP address of Target Server> target-port <Port on Target Server> /
protocol {udp | tcp} format {syslog | splunk | cef | leef | generic | json | /
logrhythm | rsa} [<Optional Arguments>]

Are you a member of CheckMates?

Utilizing Mutual TLS Authentication with Log Exporter

Background on Encryption and Mutual Autentication

Asymmetric Encryption

Symmetric Encryption

Mutual Authentication

Check Point Considerations

Implementation Steps (Certificate Generation)

External CA

Generate SMS Keys, Certificates

Generate Destination Log Server Keys, Certificates

Existing Internal CA

Generate SMS Keys, Certificates

Generate Destination Log Server Keys, Certificates

New Internal CA

Create and Configure Internal CA

Generate SMS Keys, Certificates

Generate Destination Log Server Keys, Certificates

Configuration Examples

Splunk (On-Prem)

Configure SMS Log Exporter

Syslog Server (On-Prem)

Configure Destination Log Server

Configure SMS Log Exporter

Smart-1 Cloud

Validation

Reference