Simplifying the OpenSSL CNF file for semi-automated certificate renewal.

Adrian_Bawn — Thu, 03 Feb 2022 01:15:59 GMT

As I am sure you are all aware there are a number of posts asking about creating a new certificate to use with Checkpoint but this is a little different.

I am trying to streamline the process of certificate renewal on our systems a little and to do this I am fashioning pre-configured CNF files with scripts that generate the CSR, submit them to the CA, and then possibly pump the resultant CER and KEY files back into the gateways.

In doing this I have been looking at the default CNF file used in the official guide and its full of a LOT of fluff that is only there for the local CA when generating self signed certificates, and is entirely pointless otherwise.

By way of comparison, a CNF file I created for another device we use was a total of 23 lines long, as compared to the checkpoint default one that's almost 400. And the resultant certificates appear identical.

Does anyone know what lines are critical for certificates to be used for the GAIA web portal, Proxy, and HTTPS inspection?

This is the short CNF file I used for my other device

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
encrypt_key = no
prompt = no
string_mask = nombstr

[ v3_req ]
basicConstraints = CA:false
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = device.domain.net
IP.1 = 10.10.10.10

[ req_distinguished_name ]
commonName = device.domain.net
0.organizationName = company
organizationalUnitName = IT
countryName = country
stateOrProvinceName = state
localityName = city

As far as i can see the only additional lines possibly needed from the Checkpoint CNF file would be this section:

[ proxy_cert_ext ]
basicConstraints=CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

But I don't see how its actually referenced in the CNF file as "proxy_cert_ext" isn't mentioned anywhere else and it doesn't appear to make any visible difference to the cert itself.

Everything else seems redundant, optional, or purely for configuring the CA which we don't need.

Does anyone see a problem with using a simplified CNF like the one above?

I know I can try it and its unlikely to break anything permanently and I can always put the old cert back, but some confidence that this is the right move would be good.

Thanks in advance.

Re: Simplifying the OpenSSL CNF file for semi-automated certificate renewal.

PhoneBoy — Thu, 03 Feb 2022 01:34:41 GMT

Are you modifying the .cnf file on the Check Point itself or a different system?
Keep in mind for HTTPS Inspection, a CA Key is required (not a regular certificate), which means the basicConstraints line is wrong for that use case.

Re: Simplifying the OpenSSL CNF file for semi-automated certificate renewal.

Adrian_Bawn — Thu, 03 Feb 2022 01:56:37 GMT

So currently following the guide we edit the existing openssl.cnf, add the appropriate SAN entries, generate a CSR and they submit that to our internal windows CA to generate a "webserver" certificate which we then import back into the device along with the relevant root certificates.

This works, and gives us a signed certificate that's valid for our domain and recognised by our internal clients, but it doesn't use the Checkpoint CA at all as far as i am aware.

It seems the HTTPS Inspection is actually a separate certificate (locally generated on the gateway) so that's a different issue. The one I am talking about is just for the GAIA and Usercheck portals I believe.

topic Simplifying the OpenSSL CNF file for semi-automated certificate renewal. in Firewall and Security Management

Simplifying the OpenSSL CNF file for semi-automated certificate renewal.

Re: Simplifying the OpenSSL CNF file for semi-automated certificate renewal.

Re: Simplifying the OpenSSL CNF file for semi-automated certificate renewal.