topic Re: https Inspection in General Topics

https Inspection

Libin_Thomas — Mon, 17 Jul 2017 14:41:19 GMT

Folks,

we are trying to do Https inspection on firewall , created CSR from firewall and got signed from 3rd party root CA.

but still https logs shows that client doent have root ca installed.

In client browser the 3rd party root ca is already there in trusted root ca .

do we need to import the certificate on client ?

as per my understanding if the CSR is signed from 3rd party trusted root CA then there is no need to import the certificate on client as the client already have the root ca in browser store.

Any thoughts

Re: https Inspection

cstueckrath — Mon, 17 Jul 2017 14:48:37 GMT

the firewall itself needs to be the root ca (or sub ca), and all your clients need to trust this root ca (or sub ca) certificate of your firewall.

You won't get a ca certificate from a 3rd party provider.

Re: https Inspection

PhoneBoy — Mon, 17 Jul 2017 16:50:11 GMT

Your firewall will need a certificate authority key that is able to generate a certificate for any site a user tries to access.

It can either be the one that is created through SmartConsole or a sub-CA created through your enterprise CA.

No globally trusted certificate authority will grant you a CA key for this purpose--it's against the terms of service.

The relevant CA key must be configured as "trusted" in your end users browsers.

Re: https Inspection

Libin_Thomas — Tue, 18 Jul 2017 18:18:06 GMT

To avoid installing a certificate on every browser, we need to generate a CSR from thecheckpoint and have it signed by a third-party, trusted CA that most major browsers will recognize and accept without a warning automatically.

this is what i am trying to do , after this step also we are seeing the certificate error from the client side

Re: https Inspection

Anthony_Joubai1 — Fri, 21 Jul 2017 16:55:44 GMT

Dear Thomas,

I'm facing the same issue as you.

I was looking for the same solution.

Generating CSR, get a Signed CRT from a CA already known by clients.

The point is, no article/sk even mention that option.

Using Threat Prevention with HTTPS Traffic

On the Documentation, it's mention how to generate the CA certificate and how to deploy.
Dameon Welch Abernathy

Dameon Welch Abernathy is right.

For that https inspection features, we need to CA feature and key, because we need to resign cert. A simple CRT is not enought for doing the job.
If an organization is providing your the sub CA key for the CheckPoint features, they could lose they CA aggrement.

I hope my clarification about Dameon's answer have clarified the issue.

regards,

Anthony Joubaire

Re: https Inspection

Arnvid_Karstad — Sat, 05 Aug 2017 21:48:29 GMT

How I solved this for some of our customers where like this:

- The customer(s) either had a multi-tier PKI solution for their Active Directory domain or we offered to install one for them.

As part of the PKI solution the customers AD CS install would have an offline Root CA (ORCA) and an Enterprise Intermediate Sub CA (EICA). The offline root (ORCA) was injected into active directory and would be trusted by all clients. We then use the following setup for creating a new "intermediate CA" signed by the EICA:

- on a machine with openssl create the following conf file.

r80.10_httpsi_sub_ca.conf

# OpenSSL intermediate CA configuration file.
# Copy to `/root/ca/intermediate/openssl.cnf`.
[ ca ]
# `man ca`
default_ca = CA_default
[ CA_default ]
# Directory and file locations.
dir = ./intermediate
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = $dir/serial
RANDFILE = $dir/private/.rand
# The root key and root certificate.
private_key = $dir/private/intermediate.key.pem
certificate = $dir/certs/intermediate.cert.pem
# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/intermediate.crl.pem
crl_extensions = crl_ext
default_crl_days = 30
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = 375
preserve = no
policy = policy_loose
[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
# Options for the `req` tool (`man req`).
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
# Extension to add when the -x509 option is used.
x509_extensions = v3_ca
[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
emailAddress = Email Address
# Optionally, specify some defaults.
countryName_default = GB
stateOrProvinceName_default = England
localityName_default =
0.organizationName_default = Alice Ltd
organizationalUnitName_default =
emailAddress_default =
[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always
[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Run the following commands to create the Intermediate SUB CA for HTTPSI

openssl genrsa -aes256 -out r80.10gw_httpsi_sub_ca_intermediate.key.pem 4096
openssl req -config r80.10_httpsi_sub_ca.conf -new -sha256 \
-key r80.10gw_httpsi_sub_ca_intermediate.key.pem \
-out r80.10gw_httpsi_sub_ca.intermediate.csr.pem

Take the CSR to the AD EICA and sign the certificate. Take the signed cert file back - and create a P12 with OpenSSL and import that P12 into your Check Point configuration.

For enterprise/company users - the signing sub CA is trusted by default

For guest users - redirect them to a page which tells them how to download, install and trust the CRT file

- Arnvid

Re: https Inspection

Arnvid_Karstad — Sat, 05 Aug 2017 21:54:35 GMT

I edited the configuration file part of the openssl command as my local file was named slightly differently than the one I used as example

Re: https Inspection

PhoneBoy — Sat, 05 Aug 2017 21:56:13 GMT

While I agree your approach would work for employees of a given company, a typical user of guest WiFi is unlikely to go through the trouble of installing and trusting a third party CA certificate.

Re: https Inspection

Arnvid_Karstad — Sat, 05 Aug 2017 22:06:12 GMT

In most of these installations the installation is running heavy on Application Control, DLP and now DA - and there's been very little resistance from guests to install the 3rd party CA. There are however mobile only "guest" wireless access in some cases - and there there is no https-inspection either. One of these installation protect users from about 20 different countries with different legal issues to handle.

Re: https Inspection

Sagar_Manandhar — Sun, 06 Aug 2017 03:43:24 GMT

Is it possible that we push the certificate using the group policy from the AD group. does it work for the the organization clients? .

Re: https Inspection

PhoneBoy — Sun, 06 Aug 2017 04:02:09 GMT

It's one of the approaches we recommend--using GPO to push the certificate authority.

Keep in mind this will only work for the key store in Windows and will not work for certificate stores that might exist in other applications (e.g. Firefox, Java).

Re: https Inspection

Arnvid_Karstad — Sun, 06 Aug 2017 08:05:55 GMT

The way to distribute a new CA through AD is like this:

certutil -dspublish -f "pkiorca_Root CA.crt" RootCA

certutil –dspublish -f "pkiorca_Root CAcrl"

This is how you automatically enroll it

Also like this:

In the DC, Start -> Administrative Tools -> Group Policy Management. From the left pane, expand the forest name -> expand Domains -> expand the relevant domain name -> right click on “Default domain policy” -> Edit. From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> expand “Public Key Policies” -> right click on “Trusted Root Certification Authorities” -> Import -> click Next -> click Browse to locate the CRT file from the Root CA (C:\Windows\System32\CertSrv\CertEnroll) -> click Open -> click Next twice -> click Finish -> click OK.

Then you do not need to distribute the intermediate encryption CA to any clients.

This is part of implementing an PKI solution in your organization.

Re: https Inspection

Stuart_Green — Thu, 10 Aug 2017 16:33:58 GMT

Easiest way to achieve this is to download the certificate from the gateway and install it into the System Roots certificate store on each PC or deploy it out through GPO in AD.

For Firefox and Java (and maybe Chrome) you'll need to install the certificate into their certificate stores.

On macOS, import the certificate into the System keychain and update the trust settings to Always Trust. Restart Safari or Chrome if you had them open when you did this.

Remember also that if you're using HTTPS Inspection on a system that is also using SandBlast Mobile, you'll need to import the certificate into your SandBlast Mobile admin dashboard otherwise you'll be plagued with alerts for MITM attacks.

HTH

Re: https Inspection

cezar_varlan1 — Wed, 12 Dec 2018 14:06:13 GMT

Arnvid Karstad‌ you are a lifesaver!

Check Point does not have a publicly accessible resource where it explains how to create the CSR and how to convert, import the certificates if you do want to do your SSL inspection with third party CA/SubCA. For a fact i know there is an internal document circulating within the SE community but there is no SK published.

After many tries and errors i did use your conf and managed to make everything work.

Just to point out the last steps missing from the original post:

"Take the CSR to the AD EICA and sign the certificate. "

Once you have the CSR you need to go to https://<IP_OF_CA>/certsrv and Request a certificate then "sumit advanced request"

And pick the Template for Subordinate CA.

After this is generated export the Base64 encoded version and move it to the CP Gateway.

Also go back to the https://<IP_OF_CA>/certsrv and also ask to export the Base64 version of the public CA "Download a CA" and select "Download CA Certificate Chain".

Take both exported SubCA.p7b and CA Public cert and move them to the Security Gateway.

You need to issue the commands (notice it's cpopenssl and not openssl) in order to convert the certificate to the expected format (this is taken from sk69660😞

#cpopenssl pkcs7 -print_certs -in <SubCA.p7b> -out <subCA.cer>

<SubCA.p7b> --> exported as base64 from the CA

<subCA.cer> --> the actual file you will use in the below command, now converted to correct format

Then proceed with the step mentioned in the original post:

"and create a P12 with OpenSSL and import that P12 into your Check Point configuration."

#cpopenssl pkcs12 -export -in <subCA.cer> -inkey <csr_key.key> -certfile <public_CA.cer> -out <final_subCA_for_GW.p12>

<subCA.cer> -- exported after sign request and converted according to the previous instruction

<csr_key.key> -- keyfile generated with the CSR

<csr_key.key> -- exported public CA

<final_subCA_for_GW.p12> -- the actual certificate that is to be imported to the Security Gateway Smart Console

Re: https Inspection

Arnvid_Karstad — Wed, 12 Dec 2018 14:14:12 GMT

Hi Cezar Varlan‌

The reason for using openssl vs cpopenssl is that I did everything on a different Linux server (not Gaia) - and imported it that way. You are correct that the procedure on Gaia would need cpopenssl.

Personally I would hope the procedure could make it into an SK for everyone to easily find when searching as I too had a few trial and errors to get this to work properly.

This documentation was made after doing a few 2 tier and 3 tier PKI implementations for customers - a few things became a bit more clear to me in terms of what is a good way to create and distribute these intermediate signing CA authorities.

- Arnvid