https Inspection

Discussion created by Libin Thomas on Jul 17, 2017
Latest reply on Dec 12, 2018 by Arnvid Karstad

Like • Show 3 Likes3
Comment • 14

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

Outcomes

14 Replies

Christian Stueckrath Jul 17, 2017 7:51 AM
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.
1 person found this helpful
Like • Show 0 Likes0
Actions
Dameon Welch-Abernathy Jul 17, 2017 9:50 AM
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.
1 person found this helpful
Like • Show 0 Likes0
Actions
Libin Thomas Jul 18, 2017 11:18 AM

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
Like • Show 0 Likes0
Actions
Anthony Joubaire Jul 21, 2017 10:01 AM
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
Like • Show 0 Likes0
Actions
Arnvid Karstad Aug 5, 2017 2:52 PM
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
3 people found this helpful
Like • Show 1 Like1
Actions
- Arnvid Karstad @ Arnvid Karstad on Aug 5, 2017 2:56 PM
  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
  Like • Show 0 Likes0
  Actions
- Dameon Welch-Abernathy @ Arnvid Karstad on Aug 5, 2017 2:56 PM
  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.
  Like • Show 0 Likes0
  Actions
  - Arnvid Karstad @ Dameon Welch-Abernathy on Aug 5, 2017 3:06 PM
    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.
    Like • Show 0 Likes0
    Actions
- cezar varlan @ Arnvid Karstad on Dec 12, 2018 6:07 AM
  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
  Like • Show 1 Like1
  Actions
  - Arnvid Karstad @ cezar varlan on Dec 12, 2018 6:14 AM
    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
    Like • Show 2 Likes2
    Actions
Sagar Manandhar Aug 5, 2017 8:43 PM
Is it possible that we push the certificate using the group policy from the AD group. does it work for the the organization clients? .
Like • Show 0 Likes0
Actions
- Dameon Welch-Abernathy @ Sagar Manandhar on Aug 5, 2017 9:02 PM
  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).
  1 person found this helpful
  Like • Show 1 Like1
  Actions
- Arnvid Karstad @ Sagar Manandhar on Aug 6, 2017 4:22 AM
  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.
  2 people found this helpful
  Like • Show 0 Likes0
  Actions
Stuart Green Aug 10, 2017 9:35 AM
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

S
1 person found this helpful
Like • Show 1 Like1
Actions

Incoming Links

This Week in CheckMates: Week of 7 August 2017

https Inspection

Outcomes

Related Content

Recommended Content

Incoming Links