HTTPS inspection - Create a CSR for an external CA to use for the outbound certificate

[Emil_T]

How can I create a new CSR  (Certificate Signing Request)  for outbound certificate for external CA ? The CA is a windows CA server.

[the_rock]

Not sure if below steps make 100% sense, but looks okay to me.

Andy

******************

1. Decide Where to Generate the CSR

You can generate the CSR either:

• On the Check Point Security Gateway / Management Server (Gaia CLI or SmartConsole)

• Externally (Windows/Linux) and then import the signed certificate + private key

Best practice: generate the CSR directly on the Check Point box where the private key will be used, so the key never leaves the device.

---

2. Generate CSR in Gaia Portal (Easiest)

1. Log into the Gaia Portal (https://<mgmt_or_gateway_IP>).

2. Go to:
   Device > Certificates > Outgoing Certificates

3. Click Add > Create Certificate Signing Request (CSR).

4. Fill in the fields:

   • CN (Common Name): typically the FQDN used for outbound TLS (e.g., proxy.company.com)

   • O (Organization), OU, L, ST, C as required by your CA policy

   • Key length: 2048 or 3072 bits (depending on your CA requirements)

5. Save/Generate → This will create a .csr file.

6. Download the CSR file.

---

3. Submit CSR to Windows CA

On your Windows CA server:

1. Open Certification Authority MMC.

2. Right-click the CA → All Tasks → Submit new request.
   Or, if using web enrollment, open:
   http://<CAserver>/certsrv → Request a certificate → Advanced certificate request → Submit CSR.

3. Choose the correct certificate template (e.g., Web Server, Subordinate CA, etc., depending on usage).

4. Submit and download the signed certificate (usually .cer or .p7b).

---

4. Import Signed Certificate Back into Gaia

1. Go back to Gaia Portal → Device → Certificates → Outgoing Certificates.

2. Select your pending CSR request.

3. Click Import Certificate and upload the .cer (or export from CA as Base64 if needed).

4. Once imported, the status will change to Valid.

---

5. (Optional) CLI Method

If you prefer CLI:

# Create a new private key and CSR openssl req -new -newkey rsa:2048 -nodes -keyout outbound.key -out outbound.csr

• Transfer the .csr to your Windows CA, sign it, then bring the .cer back.

• Import both .key and .cer into Check Point with cpca_client or via Gaia Portal.

[Emil_T]

Hi

There is no such menu in Gaia GUI: Device > Certificates > Outgoing Certificates

I will try what emmap suggested

[the_rock]

Fair enough, its an official CP documentation anyway.

Andy

[emmap · Accepted solution]

We have it documented here: https://support.checkpoint.com/results/sk/sk165856

[the_rock]

Perfect, even better!

Andy

[Emil_T]

I followed sk165856, But instead of step 6 i used the method below (since step 6 failed and generated this error: unable to load certificates

-Run "cpopenssl pkcs12 -export -in inspection-ca.cer -inkey inspection-key.pem -out inspection.pfx"

-After got the certificate in .pfx format, rename it to .p12 format

-Import to smart console.

https://community.checkpoint.com/t5/Management/OpenSSL-latest-version-support-for-pkcs12-cert-creati...

[emmap]

OK, you haven't included the rootCA in there, so if you have trust issues from endpoints that are trusting that root CA that might be why. Let us know how you go anyway.

[Emil_T]

Thx! I'll let you know.

The root-ca is the internal organizational ca, so to the best of my knowledge, every domain member should trust it.

[the_rock]

Maybe it was wrong cert extension?

[Emil_T]

I'm not sure. I don't believe file extensions really matter when using openssl

[the_rock]

I am fairly sure to import it into smart console, it would have to be .p12 extension, but I could be mistaken.

Andy

[Emil_T]

You are correct. Smart console only looking for p12 file. That's why there is a rename extension step in the workaround I guess.

[the_rock]

So, on step 6, since you said thats where it faisl it only gives that error unable to load certificate?

Andy

[Emil_T]

Correct. And seems like I'm not the only one. But with the workaround everything seems to be working. I already made some test and the endpoint can see the certificate that the firewall issues and it is trusted as the root-ca is a trusted CA of the endpoint

[the_rock]

Well, as long as all the relevant certs are included in truster root store on user's PC, then you are good.

I made post about this as well.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Https-inspection-tip/m-p/219139