Overview

 

1. When we install a Check Point Operating System (say Gaia) and boot the device for the first time, by default a Private Key, CSR (using the default parameters) & a Self-Signed Certificate will be created.

While Generating the CSR, it took the default parameters and the CN field as the interface IP-address defined during the OS installation of this VM (192.168.1.1 on CP Devices).

The Private Key & Self-Signed Certificate will be stored in /web/conf directory of that device.

2. As it’s a Self-Signed Certificate (not from a Trusted CA), browsers will throw a HTTPS Certificate Warning while accessing the device (Gaia Portal / SSL VPN portal / RA VPN Client).

3. In Check Point below features will use the SSL Certificates of the device for their functionality:

• Gaia Portal
• IPSec VPN (Certificate Based Tunnel)
• Remote Access VPN
• SSL VPN

 
4. There will be a requirement for any organization to replace the Self-Signed Certificate with a Trusted CA SSL Certificate to give the confidence to users accessing these features.

5. The Trusted CA SSL Certificate installation needs the following to be taken care:

• CSR Generation on the Check Point device.
• Purchase an SSL Certificate from the Trusted CA.
• Request for an SSL Certificate for the generated CSR.
• Download & Install the Trusted SSL CA on the Check Point device.

 

SSL Certificate for IPSec & Remote Access VPN Feature

 
1. Our VPN Gateway’s public IP-address (49.206.27.13) is associated with the domain name www.rkfw-vpn.tk . If we attempt to access the VPN Gateway using RA VPN client then users get Certificate Warning because of the Self-Signed Certificate associated with the VPN feature of this Gateway issued by the Management Server’s Internal CA.

2. For VPN feature, installing a trusted 3^rd party SSL Certificate involves different approach,

• Creating a Trusted 3^rd Party Root CA on Check Point
• Creating a Trusted 3^rd Party Intermediate CA on Check Point
• Generating a CSR from for the VPN Gateway.
• Request for an SSL Certificate using the generated CSR from Trusted 3^rd Party CA.
• Install the SSL Certificate on the VPN Gateway.

 
3. For any Trusted 3^rd Party CA that you are planning to buy the license from, will provide its Root CA & Intermediate CA Certificate to download online. In this scenario we are considering SSL.com CA & its Root & Intermediate CA can be downloaded below,

4. Let’s get started with defining the Trusted CA’s on our Check Point setup.

• Create the Trusted Root CA for SSL.com,

 

• Select the OPSEC PKI tab & inside the “Certificate” section, click on Get to insert the Root CA certificate & Browse the Root CA Certificate for SSL.com (a .crt or .cer file),

 

• You will be able to see the content of this Root CA certificate, Click OK to accept the Root CA Certificate.

 

• In the “Retrieve CRL from” section, make sure that only “HTTP Server(s)” is selected. Click OK to save this object.

 

• Under Trusted CA section, along with Management Server’s internal_ca you can see SSL.com Root CA.

 

• Install the Database on the Management Server (with publishing the changes).

 

5. Now, define the SSL.com Intermediate CA (Subordinate CA) using the Intermediate CA Certificate that we downloaded before.

• Provide a name for the Intermediate CA and don’t worry about the Trusted CA section showing as “not initialized”.

 

• Select the OPSEC PKI tab, inside the “Certificate” section, click Get to insert the Intermediate CA certificate & Browse the Intermediate CA Certificate for SSL.com (a .crt or .cer file),

 

• You will be able to see the content of this Intermediate CA certificate, Click OK to accept the Intermediate CA Certificate.

 

• We can see the Intermediate CA object in the Subordinate CA section.

 

• Install the Database on the Management Server (with publishing the changes).

 

• Open the Intermediate CA object and we can see our Root CA Object SSL_ROOT_CA under Trusted CA section.

 

7. Open the VPN Gateway object and go to the IPSec VPN section.

8. Click on Add and define our Trusted SSL Certificate Properties to generate the CSR out of it. Select Intermediate CA object (SSL_INT_CA) under CA to enroll from section.

9. Click on Generate to generate the CSR

10. Define the DN (Distinguished Name) as follows,

CN=DomainName,OU=Department,O=Organization,L=Locality,ST=State,C=Country

In our case let’s define a Domain Name for our VPN Gateway as rkfw-vpn.tk,

CN=www.rkfw-vpn.tk,OU=NWSec,O=RKMillets,L=Bengaluru,ST=Karnataka,C=IN

Click OK and a CSR is created after this.

11. Under Certificate Repository we can see our Trusted 3^rd Party CA entry.

12. Click on View and copy the CSR content from it.

13. Purchase an SSL Certificate and provide this CSR to get an SSL Certificate for our VPN Gateway.

• Start the SSL Certificate wizard and paste the CSR content that we have copied previously.

 

• We will do the domain validation for rkfw-vpn.tk domain using the DNS CNAME record method.

 

• Define a CNAME record on our DNS Server pointing to the SSL.COM domain. Meaning point the CNAME

_DA32C857952DD9CCB90E8B6B632C5704.rkfw-vpn.tk

to

53C815CEAE3811B704567FCA6D10FD48.757FB0072F901D7E3C1874E7AD949571.df79357109
.ssl.com

• Once we add a CNAME record, the domain validation of the SSL.com will pass.

 

14. Now, Download the SSL Certificate for our VPN Gateway domain.

15. Go back to the VPN Gateway Object and IPSec VPN section. Select the Trusted 3^rd Party CA that we have added.

16. Click on Complete, and upload the domain certificate (www.rkfw-vpn.tk) that we downloaded from the SSL.com CA.

Accept the trusted domain certificate for our VPN Gateway.

17. We can delete the Default Self-Signed VPN Certificate to make use of our Trusted CA SSL Certificate. For any future Certificate based S2S VPN communication, this certificate will be used which can be trusted by the Peer End VPN Gateway.

18. Under VPN Clients section, Select our certificate.

19. Install the database on the Management Server.

20. Install the Policy on our VPN Gateway.

21. Now, access the VPN Gateway using the RA VPN Client,

Unlike the previous attempt, we won’t get Certificate Warning because of the mapping of our Trusted 3^rd Party CA SSL Certificate which our Operating System or Browser trusts.

22. You can use this trusted 3^rd party SSL Certificate which is mapped to our domain (www.rkfw-vpn.tk) for other Check Point features like SSL VPN, Gaia Portal. But on the SmartConsole the option to export this certificate is greyed-out (reason unknown) under IPSec VPN section of VPN Gateway.

23. We have an alternative for this concern – export_p12 command.

• If you remember while generating the CSR using our trusted CA’s, we chose an option to store our keys on the Management Server & our trusted CA certificate too resides on the Management Server.

 

• So, take the SSH to Management Server which is managing the VPN Gateway and run the export_p12 command, whose Syntax goes like this:

# export_p12 -obj <Name_of_GW_Object> -cert <NickName_of_CA_Repository> -file <Name_of_Output_P12_File.p12> -passwd <Password_to_Open_Output_P12_File>

In our case it is:

# export_p12 -obj RK-FW-BNG -cert MY_SSL_CERT -file /home/admin/rkfw.p12 -passwd SomeComplexPswd

• Copy the output .p12 certificate file and use it on the other Check Point features.

 

SSL Certificate for Gaia Portal

 
Note: If you have the trusted 3^rd party CA SSL Certificate for VPN feature then go to step 16.

1. Our Gateway is defined with a domain name www.rkfw.tk.

2. While accessing the Gaia Portal we get a Browser warning on the device Self-Signed SSL Certificate, which is stored in the /web/conf directory of this device.

3. If we want to avoid such warnings then map an SSL Certificate to our Gateway’s Gaia Portal. Getting an SSL Certificate for the Gateway involves the same steps as like a Web Server.

4. In Check Point we have a port of OPENSSL tool which we call it CPOPENSSL.

5. Generate the CSR & a Private Key using CPOPENSSL tool in any directory (say /home/admin).

# cpopenssl req -new -newkey rsa:2048 -nodes -out <A_CSR_File> -keyout <A_Private_Key> -config $CPDIR/conf/openssl.cnf

In our case:

# cpopenssl req -new -newkey rsa:2048 -nodes -out rkfw.csr -keyout rkfw.key -config $CPDIR/conf/openssl.cnf

Provide the CSR details such as the CN or Domain Name, in our case let’s consider www.rkfw.tk

6. Output of the above CPOPENSSL Command will be a CSR file & Private Key file.

7. Copy the CSR file (rkfw.csr) content.

8. Purchase an SSL Certificate and provide this CSR to get an SSL Certificate for our Gateway.

• Start the SSL Certificate wizard and paste the CSR content that we have copied previously.

 

• We will do the domain validation for www.rkfw.tk domain using the DNS CNAME record method.
• Define a CNAME record on our DNS Server pointing to the SSL.COM domain. Meaning point the CNAME

 
_B746756517EC88F730C4D7F96C7A8CD0.rkfw.tk

to

986164AEBD20FBB44C105EFEBA1A4E9C.D21646171B6F4BA5ADF93463C06E6964.7ad76d7a9b
.ssl.com

• Once we add a CNAME record, the domain validation of the SSL.com will pass.

 

9. Now, Download the SSL Certificate for our Gateway domain. Choose Apache as Server type.

The downloaded zip file has the domain certificate (www_rkfw_tk.crt) & a bundled certificate (ca-bundled-client.crt) of our SSL.COM Root & Intermediate certificate.

10. Copy these two files on to our Gateway where we generated the CSR (/home/admin).

11. Merge the content of domain certificate & the bundled CA Certificate in such way that it resembles:

—–BEGIN CERTIFICATE—–

(Your Primary SSL certificate: www_rkfw_tk.crt)

—–END CERTIFICATE—–

—–BEGIN CERTIFICATE—–

(Your Intermediate certificate: SSL-COM-RSA-SSL-SUBCA.crt)

—–END CERTIFICATE—–

—–BEGIN CERTIFICATE—–

(Your Root certificate: SSL-COM-ROOT-CERTIFICATION-AUTHORITY-RSA.crt)

—–END CERTIFICATE—–

So, combine the two certificate files that we have downloaded from SSL.COM and create a single certificate file (rkfw_with_cert_chain.crt) which will have the above format.

12. Rename the trusted SSL Certificate file (rkfw_with_cert_chain.crt) and the Private Key file (rkfw.key) as server.crt and server.key respectively.

13. Replace our Gateway’s default Self-Signed Certificate & the Private Key stored in /web/conf directory with our trusted SSL Certificate & the Private Key stored in /home/admin directory.

Note: Backup the original server.crt & server.key file stored in /web/conf before doing the changes.

14. From the /home/admin directory, generate a .p12 certificate file (supported file type on our SmartConsole) by making use of our trusted SSL Certificate & it’s Private Key. Run the below command to create a .p12 file:

# cpopenssl pkcs12 -export -out <Output_p12_File> -in <Certificate_File> -inkey <Certificate’s_Private_Key>

In our case it is:

# cpopenssl pkcs12 -export -out rkfw_final.p12 -in server.crt -inkey server.key

Provide the .p12 export password while generating the file.

15. Copy this .p12 file which we will be using on our SmartConsole.

16. Open the Gateway Object and go to Platform Portal section.

17. Click on Import and map the .p12 file that we have copied from the device.

Enter the export password that we set while generating the .p12 file.

18. The SSL Certificate that we have imported is valid and mapped to our domain (www.rkfw.tk) ,

19. Click on OK and Save the configuration by Publishing the changes. Install the Database on the Management Server.

20. Install the Policy on the Gateway Object.

21. Now, try to access the Gateway’s Gaia Portal using the domain name www.rkfw.tk ,

We are no more getting the SSL Certificate warning on the browser, as it is issued by a Trusted CA -SSL.COM which our Operating System or Browser trust upon.
 

SSL Certificate for Mobile Access / SSL VPN

1. Mobile Access VPN portal will also use the Self-Signed Certificate issued by the Management Server’s Internal CA by default, which gives a Certificate Warning on any browser.
 

2. We can use the Trusted 3^rd Party CA Certificate that we have generated earlier on Mobile Access VPN Feature by importing the certificate in .p12 format.

3. Install the Database on the Management Server & Install the Policy on the Gateway. You will be able to access the Mobile Access Portal without any Certificate Warning.

SSL Certificate for HTTPS Inspection Feature (Outbound Traffic)

 
1. Our Gateway is enabled with HTTPS Inspection feature to inspect the web traffic using the Self-Signed Certificate that we created while enabling this feature.

2. We get a Certificate Warning on each user to whom HTTPS inspection rule being enforced.

3. Clearly the Self-Signed Certificate that we have created is not there either in the OS Trusted Certificate Store or Browsers Certificate Store.

4. You won’t able to resolve the above issue using a Domain Certificate associated with the Gateway, reason being the Domain Certificate are not designed to issue a certificate to some other domains. In other words, Domain Certificates can’t act as an Intermediate Certificate Authority to issue Certificates to other Domains.

You will get the below error is you do so:

5. So the Certificate that we use in HTTPS Inspection (Outbound Traffic) needs to be either a Root Certificate or Intermediate CA!. But No CA will provide the access to their Root or Intermediate Certificates & Private Key to anyone.

6. In order to avoid our original concern related to HTTPS Inspection, we have two options:

• Distribute the Self-Signed Certificate generated on the Gateway to all the User Machines Trusted Root CA repository either Manually or using Microsoft GPO – An easy Approach.
• Establish a Private PKI infrastructure for your organization and import a Certificate on to the Check Point Gateway.

 

SSL Certificate for HTTPS Inspection Feature (Inbound Server Traffic)

 

1. HTTPS Inspection rule that we have defined in the previous case was to inspect only the traffic originated from the internal users (outbound) using the Self-Signed Certificate.

2. If there is a need to inspect the traffic from Internet destined to an Internal Server, then you have to define an Inbound HTTPS Inspection Rule.

3. As we are aware if there is a Man in the Middle for any HTTPS Traffic, the end user will be notified with the Certificate Warning.

4. So, you need to import the Domain Certificate of the Server on the Gateway so that the Gateway can give a healthy feel to the internet user who’s accessing the Server even though there is an interception of the HTTPS traffic destined to the Server.

5. Let’s consider our RKMILLETS website www.rkmillet.tk , if we want to inspect this traffic then we need to:

• Import the Server’s Domain Certificate on the Check Point Gateway.
• Create an Inbound HTTPS Inspection Rule.

 
6. Import the RKMILLETS Server’s domain certificate (.p12 extension) under Server Certificate section of the HTTPS Inspection,

• On any Linux machine copy the RKMILLETS Server’s Domain Certificate & it’s Private Key and then generate the .p12 certificate.

 

• Copy the Server’s .p12 certificate to your local machine and then import it on the Gateway.

 

7. Define the Inbound HTTPS Inspection Rule on the Gateway by using the Server’s Certificate that we have imported.

8. Install the Database on the Management Server & then Install the Policy on the Gateway and you are done with the configuration to inspect the Server’s Inbound traffic.