Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Quinn_Yost
Contributor
Jump to solution

Working with OPSEC clients (SHA256/SHA1)

Within the Check Point knowledge base, there seems to be a variety of resoruces which address the inability of OPSEC applications to connect to r80.   All of these fall back to the SDK for OPSEC not being updated until r80 was formally released.

sk103840 - Describes the issue and provides a process for setting the internal CA to use SHA1 from just after install.

sk109618 - Describes how to temporarily set the CA to issue a SHA1 certificate

sk110559 - Describes how to recreate the SIC  certificate using SHA1 if it had been previously created as SHA256

The challenge is, what really works and won't require re-SICing  with the objects already communicating and using SHA256?

1 Solution

Accepted Solutions
Quinn_Yost
Contributor

Answering my own question with a cross-post...

I've been fighting this one for a little bit myself and I'll agree with the CheckPoint responses above, "Yes, the OPSEC API is still [mostly] supported".

However:

  1. R80 uses a sha256 hash on the certificate by default.   The OPSEC SDK was updated to include this support early in the summer (sk110425: OPSEC SDK - SHA-256 support ), and is still considered EA.   It is quite likely that your application has not yet released updated binaries that permit use of sha256.  sk109618 (OPSEC SIC connection fails) has instructions for resetting a single opsec application to use sha1, but in my experience it will still not work if the cp_mgmt is still sha256.  To get those application to connect to your R80 infrastructure, you will need to force cpca to issue sha1 certificates as shown in sk103840 (SHA-1 and SHA-256 certificates in Check Point Internal CA (ICA)).  This sk specifically deals with post-install or post-upgrade instruction, before any other configuration has been done.  To change the cp_mgmt certificate anytime later, you should reference sk110559 ("Bad certificate - SIC error 301 for lea" error when fetching 3rd party OPSEC server certificate) which has instructions for SMS and MDS.
  2. There is a small note a the bottom of sk110425, "CPMI is no longer fully supported in R80 (regardless of the SDK)".  Keep this in mind if you plan to use a third party firewall management tool.

View solution in original post

1 Reply
Quinn_Yost
Contributor

Answering my own question with a cross-post...

I've been fighting this one for a little bit myself and I'll agree with the CheckPoint responses above, "Yes, the OPSEC API is still [mostly] supported".

However:

  1. R80 uses a sha256 hash on the certificate by default.   The OPSEC SDK was updated to include this support early in the summer (sk110425: OPSEC SDK - SHA-256 support ), and is still considered EA.   It is quite likely that your application has not yet released updated binaries that permit use of sha256.  sk109618 (OPSEC SIC connection fails) has instructions for resetting a single opsec application to use sha1, but in my experience it will still not work if the cp_mgmt is still sha256.  To get those application to connect to your R80 infrastructure, you will need to force cpca to issue sha1 certificates as shown in sk103840 (SHA-1 and SHA-256 certificates in Check Point Internal CA (ICA)).  This sk specifically deals with post-install or post-upgrade instruction, before any other configuration has been done.  To change the cp_mgmt certificate anytime later, you should reference sk110559 ("Bad certificate - SIC error 301 for lea" error when fetching 3rd party OPSEC server certificate) which has instructions for SMS and MDS.
  2. There is a small note a the bottom of sk110425, "CPMI is no longer fully supported in R80 (regardless of the SDK)".  Keep this in mind if you plan to use a third party firewall management tool.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events