Public Key Infrastructure

Need for Integration with Different PKI Solutions

X.509-based PKI solutions provide the infrastructure that enables entities to establish trust relationships between each other based on their mutual trust of the Certificate Authority (CA). The trusted CA issues a certificate for an entity, which includes the entity's public key. Peer entities that trust the CA can trust the certificate - because they can verify the CA's signature - and rely on the information in the certificate, the most important of which is the association of the entity with the public key.

IKE standards recommend the use of PKI in VPN environments, where strong authentication is required.

A Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. taking part in VPN tunnel establishment must have an RSA key pair and a certificate issued by a trusted CA. The certificate contains details about the module's identity, its public key, CRL retrieval details, and is signed by the CA.

When two entities try to establish a VPN tunnel, each side supplies its peer with random information signed by its private key and with the certificate that contains the public key. The certificate enables the establishment of a trust relationship between the Security Gateways; each Security Gateway uses the peer Security Gateway public key to verify the source of the signed information and the CA's public key to validate the certificate's authenticity. In other words, the validated certificate is used to authenticate the peer.

Every deployment of Check Point Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. includes an Internal Certificate Authority (ICA Internal Certificate Authority. A component on Check Point Management Server that issues certificates for authentication.) that issues VPN certificates for the VPN modules it manages. These VPN certificates simplify the definition of VPNs between these modules.

Situations can arise when integration with other PKI solutions is required, for example:

• A VPN must be established with a Security Gateway managed by an external Security Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server.. For example, the peer Security Gateway belongs to another organization which utilizes Check Point products, and its certificate is signed by its own Security Management Server ICA.

• A VPN must be established with a non-Check Point VPN entity. In this case, the peer's certificate is signed by a third-party CA.

• An organization may decide, for whatever reason, to use a third party CA to generate certificates for its Security Gateways.

Supporting a Wide Variety of PKI Solutions

Check Point Security Gateways support many different scenarios for integrating PKI in VPN environments:

• Multiple CA Support for Single VPN Tunnel - Two Security Gateways present a certificate signed by different ICAs.

• Support for non-ICA CAs - In addition to ICA, Security Gateways support the following Certificate Authorities:

• External ICA - The ICA of another Security Management Server

• Other OPSEC certified PKI solutions

• CA Hierarchy - CAs are typically arranged in a hierarchical structure where multiple CAs are subordinate to a root authority CA. A subordinate CA is a Certificate Authority certified by another Certificate Authority. Subordinate CAs can issue certificates to other, more subordinate CAs, forming a certification chain or hierarchy.

PKI and Remote Access Users

The Check Point Suite supports certificates not only for Security Gateways but for users as well. For more information, see Introduction to Remote Access VPN An encrypted tunnel between remote access clients (such as Endpoint Security VPN) and a Security Gateway. for information about user certificates.

PKI Deployments and VPN

Following are some sample CA deployments:

• Simple Deployment - internal CA

• CA of an external Security Management Server

• CA services provided over the Internet

• CA on the LAN

Simple Deployment ? Internal CA

When the VPN tunnel is established between Security Gateways managed by the same Security Management Server, each peer has a certificate issued by the Security Management Server's ICA.

CA of An External Security Management Server

If a Check Point Security Gateway is managed by an external Security Management Server (for example, when establishing a VPN tunnel with another organization's VPN modules), each peer has a certificate signed by its own Security Management Server's ICA.

Security Management Server A issues certificates for Security Management Server B that issues certificates for Security Gateway B.

CA Services Over the Internet

If the certificate of a Security Gateway is issued by a third party CA accessible over the Internet, CA operations such as registration or revocation are usually performed through HTTP forms. CRLs are retrieved from an HTTP server functioning as a CRL repository.

Security Gateways A and B receive their certificates from a PKI service provider accessible via the web. Certificates issued by external CAs may be used by Security Gateways managed by the same Security Management Server to verification.

CA Located on the LAN

If the peer VPN Security Gateway certificate is issued by a third party CA on the LAN, the CRL is usually retrieved from an internal LDAP server, as shown:

Trusting An External CA

A trust relationship is a crucial prerequisite for establishing a VPN tunnel. However, a trust relationship is possible only if the CA that signs the peer's certificate is "trusted." Trusting a CA means obtaining and validating the CA's own certificate. Once the CA's Certificate has been validated, the details on the CA's certificate and its public key can be used to both obtain and validate other certificates issued by the CA.

The Internal CA (ICA) is automatically trusted by all modules managed by the Security Management Server that employs it. External CAs (even the ICA of another Check Point Security Management Server) are not automatically trusted, so a module must first obtain and validate an external CA's certificate. The external CA must provide a way for its certificate to be imported into the Security Management Server.

If the external CA is:

• The ICA of an external Security Management Server, see the R81 Security Management Administration Guide for further information

• An OPSEC Certified CA, use the CA options on the Servers and OPSEC Applications tab to define the CA and obtain its certificate

Subordinate Certificate Authorities

A subordinate CA is a Certificate Authority certified by another Certificate Authority. Subordinate CAs can issue certificates to other, more subordinate CAs, in this way forming a certification chain or hierarchy. The CA at the top of the hierarchy is the root authority or root CA. Child Certificate Authorities of the root CA are referred to as Subordinate Certificate Authorities.

With the CA options on the Servers and OPSEC Applications tab, you can define either a Certificate Authority as either Trusted or Subordinate. Subordinate CAs are of the type OPSEC, and not trusted.

Enrolling a Managed Entity

Enrollment means requesting and obtaining a certificate from a CA, for an entity.

The process of enrollment begins with the generation of a key pair. A certificate request is then created out of the public key and additional information about the module. The type of the certificate request and the rest of the enrollment process depends on the CA type.

The case of an internally managed Security Gateway is the simplest, because the ICA is located on the Security Management Server machine. The enrollment process is completed automatically.

To obtain a certificate from an OPSEC Certified CA, Security Management Server takes the module details and the public key and encodes a PKCS#10 request. The request (which can include SubjectAltName for OPSEC certificates and Extended Key Usage extensions) is delivered to the CA manually by the administrator. Once the CA issues the certificate the administrator can complete the process by importing the certificate to the Security Management Server.

A certificate can also be obtained for the Security Gateway with Automatic Enrollment. With Automatic Enrollment, you can automatically issue a request for a certificate from a trusted CA for any Security Gateway in the community. Automatic Enrollment supports the following protocols:

• SCEP

• CMPV1

• CMPV2

Note - During SCEP enrollment, some HTTP requests may be larger than 2000 bytes, and may be dropped by the HTTP protocol inspection mechanism if enabled. A change of the default value will be required to enable these HTTP requests. If enrollment still fails, enrollment must be done manually. For more information, see the R81 Threat Prevention Administration Guide.

Validation of a Certificate

When an entity receives a certificate from another entity, it must:

1. Verify the certificate signature, i.e. verify that the certificate was signed by a trusted CA. If the certificate is not signed directly by a trusted CA, but rather by a subsidiary of a trusted CA, the path of CA certificates is verified up to the trusted CA.

2. Verify that the certificate chain has not expired.

3. Verify that the certificate chain is not revoked. A CRL is retrieved to confirm that the serial number of the validated certificate is not included among the revoked certificates.

In addition, VPN verifies the validity of the certificate's use in the given situation, confirming that:

• The certificate is authorized to perform the required action. For example, if the private key is needed to sign data (e.g., for authentication) the KeyUsage extension on the certificate - if present - is checked to see if this action is permitted.

• The peer used the correct certificate in the negotiation. When creating a VPN tunnel with an externally managed module, the administrator may decide that only a certificate signed by a specific CA from among the trusted CAs can be accepted. (Acceptance of certificates with specific details such as a Distinguished Name is possible as well).

Revocation Checking

There are two available methods useful in determining the status of a certificate:

1. CRL

2. Online Certificate Status Protocol (OCSP)

Enrolling with a Certificate Authority

A certificate is automatically issued by the Internal Certificate Authority for all internally managed entities that are VPN-capable. That is, after the administrator enables the IPsec VPN Software Blade Specific security solution (module): (1) On a Security Gateway, each Software Blade inspects specific characteristics of the traffic (2) On a Management Server, each Software Blade enables different management capabilities. in a Security Gateway or Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. object (on the General Properties page > on the Network Security tab).

The process for obtaining a certificate from an OPSEC PKI CA or External Check Point CA is identical.

CRL

VPN can retrieve the CRL from either an HTTP server or an LDAP server. If the CRL repository is an HTTP server, the module uses the URL published in the CRL Distribution Point extension on the certificate and opens an HTTP connection to the CRL repository to retrieve the CRL.

If the CRL repository is an LDAP server, VPN attempts to locate the CRL in one of the defined LDAP account units. In this scenario, an LDAP account unit must be defined. If the CRL Distribution Point extension exists, it publishes the DN of the CRL, namely, the entry in the Directory under which the CRL is published or the LDAP URI. If the extension does not exist, VPN attempts to locate the CRL in the entry of the CA itself in the LDAP server.

OCSP

Online Certificate Status Protocol (OCSP) enables applications to identify the state of a certificate. OCSP may be used for more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. When OCSP client issues a status request to an OCSP server, acceptance of the certificate in question is suspended until the server provides a response.

In order to use OCSP, the root CA must be configured to use this method instead of CRL. This setting is inherited by the subordinate CAs.

CRL Prefetch-Cache

Since the retrieval of CRL can take a long time (in comparison to the entire IKE negotiation process), VPN stores the CRLs in a CRL cache so that later IKE negotiations do not require repeated CRL retrievals.

The cache is pre-fetched:

• every two hours

• on policy installation

• when the cache expires

If the pre-fetch fails, the previous cache is not erased.

Note - The ICA requires the use of a CRL cache.

An administrator can shorten the lifetime of a CRL in the cache or even to cancel the use of the cache. If the CRL Cache operation is canceled, the CRL must be retrieved for each subsequent IKE negotiation, thus considerably slowing the establishment of the VPN tunnel. Because of these performance implications, we recommend that you only disable CRL caching when the level of security demands continuous CRL retrieval.

Special Considerations for the CRL Pre-fetch Mechanism

The CRL pre-fetch mechanism makes a "best effort" to obtain the most up to date list of revoked certificates. However, after the cpstop and cpstart commands have been executed, the cache is no longer updated. The Security Gateway continues to use the old CRL for as long as the old CRL remains valid (even if there is an updated CRL available on the CA). The pre-fetch cache mechanism returns to normal functioning only after the old CRL expires and a new CRL is retrieved from the CA.

In case there is a requirement that after the cpstop and cpstart commands, the CRLs will be updated immediately, proceed as follows:

• After executing the "cprestart" command, run the vpn crl_zap command to empty the cache, or:

• In SmartConsole

  1. Click Menu > Global properties > Advanced > Configure.

  2. Click Certificates and PKI properties.

  3. Select flush_crl_cache_file_on_install.

  4. Click OK.

  5. Install the Access Control Policy.

When a new policy is installed, the cache is flushed, and a new CRL will be retrieved on demand.

CRL Grace Period

Temporary loss of connection with the CRL repository or slight differences between clocks on the different machines may cause valid of CRLs to be considered invalid - and thus the certificates to be invalid as well. VPN overcomes this problem by supplying a CRL Grace Period. During this period, a CRL is considered valid even if it is not valid according to the CRL validity time.

Special Considerations for PKI

Using the Internal CA vs. Deploying a Third Party CA

The Internal CA makes it easy to use PKI for Check Point applications such as site-to-site and remote access VPNs. However, an administrator may prefer to continue using a CA that is already functioning within the organization, for example a CA used to provide secure email, and disk encryption.

Distributed Key Management and Storage

Distributed Key Management (DKM) provides an additional layer of security during the key generation phase. Instead of the Security Management Server generating both public and private keys and downloading them to the module during a policy installation, the management server instructs the module to create its own public and private keys and send (to the management server) only its public key. The private key is created and stored on the module in either a hardware storage device, or via software that emulates hardware storage. Security Management Server then performs certificate enrollment. During a policy installation, the certificate is downloaded to the module. The private key never leaves the module.

Local key storage is supported for all CA types.

DKM is supported for all enrollment methods. You can configure it as a default setting:

1. In SmartConsole, click Menu > Global properties > Advanced > Configure.

2. Click Certificates and PKI properties.

3. Select use_dkm_cert_by_default.

4. Click OK.

5. Install the Access Control Policy.

Note - Generating certificates for Edge devices does not support DKM and will be generated locally on the management even if use_dkm_cert_by_default is enabled.

Configuration of PKI Operations

Trusting a CA - Step-By-Step

This section describes the procedures for obtaining a CA's own certificate, which is a prerequisite for trusting certificates issued by a CA.

In order to trust a CA, a CA server object has to be defined. The following sections deal with the various configuration steps required in different scenarios.

Trusting an ICA

A VPN module automatically trusts the ICA of the Security Management Server that manages it. No further configuration is required.

Trusting an Externally Managed CA

An externally managed CA is the ICA of another Security Management Server. The CA certificate has to be supplied and saved to disk in advance.

To establish trust:

1. In Object Explorer, click New > Server > More > Trusted CA.

   The Certificate Authority Properties window opens.

2. Enter a Name for the CA object.

3. Go to the OPSEC PKI tab.

4. Click Get.

5. Browse to where you saved the peer CA certificate and select it.

   The certificate details are shown.

   Make sure the certificate's details are correct.

   Make sure the SHA-1 and MD5 fingerprints of the CA certificate are correct.

6. Click OK.

Trusting an OPSEC Certified CA

The CA certificate has to be supplied and saved to the disk in advance.

Note - In case of SCEP automatic enrollment, you can skip this stage and fetch the CA certificate automatically after configuring the SCEP parameters.

The CA's Certificate must be retrieved either by downloading it with the CA options in the Certificate Authority object, or by obtaining the CA's certificate from the peer administrator in advance.

Define the CA object according to the following steps

1. In Object Explorer, click New > Server > More > Trusted CA or Subordinate CA.

   The Certificate Authority Properties window opens.

2. Enter a Name for the CA object.

3. On the OPSEC PKI tab:

   • For automatic enrollment, select Automatically enroll certificate.

   • From the Connect to CA with protocol, select the protocol used to connect with the certificate authority, either SCEP, CMPV1 or CMPV2.

   Note - For entrust 5.0 and later, use CMPV1.

4. Click Properties:

   • If you chose SCEP as the protocol, in the Properties for SCEP protocol window, enter the CA identifier (such as example.com) and the Certification Authority/Registration Authority URL.

   • If you chose CMPV1 as the protocol, in the Properties for CMP protocol - V1 window, enter the applicable IP address and port number. (The default port is 829).

   • If you chose CMPV2 as the protocol, in the Properties for CMP protocol -V2 window, decide whether to use direct TCP or HTTP as the transport layer.

     Note - If Automatic enrollment is not selected, then enrollment will have to be performed manually.

5. Choose a method for retrieving CRLs from this CA.

   If the CA publishes CRLs on HTTP server choose HTTP Server(s).

   Certificates issued by the CA must contain the CRL location in an URL in the CRL Distribution Point extension.

   If the CA publishes CRL on LDAP server, choose LDAP Server(s).

   In this case, you must define an LDAP Account Unit as well. See the R81 Security Management Administration Guide for more details about defining an LDAP object.

   In the LDAP Account Unit Properties window, on the General tab, make sure to check the CRL retrieval.

   Certificates issued by the CA must contain the LDAP DN on which the CRL resides in the CRL distribution point extension.

6. Click Get.

7. If SCEP is configured, it will try to connect to the CA and retrieve the certificate. If not, browse to where you saved the peer CA certificate and select it.

   The certificate is fetched. Verify the certificate's details. Display and validate the SHA-1 and MD5 fingerprints of the CA certificate.

8. Click OK.

Certificate Revocation (All CA Types)

A certificate issued by the Internal Certificate Authority it is revoked when the certificate object is removed. Otherwise, the CA administrator controls certificate revocation with the options on the Advanced tab of the CA object. In addition, the certificate must be removed from the Security Gateway.

A certificate cannot be removed if the Security Management Server infers from other settings that the certificate is in use, for example, that the Security Gateway belongs to one or more VPN communities and this is the only certificate of the Security Gateway.

Certificate Recovery and Renewal

When a certificate is revoked or becomes expired, it is necessary to create another one or to refresh the existing one.

Recovery and Renewal with Internal CA

Removal of a compromised or expired certificate automatically triggers creation of a new certificate, with no intervention required by the administrator. To manually renew a certificate use the Renew button on the VPN page of the Security Gateway object.

Note - A Security Gateway can have only one certificate signed by one CA. When the new certificate is issued, you will be asked to replace the existing certificate signed by the same CA.

CA Certificate Rollover

CA Certificate Rollover is a VPN feature that enables rolling over the CA certificates used to sign client and Security Gateway certificates for VPN traffic, without risk of losing functionality at transition.

To achieve a gradual CA certificate rollover, CA Certificate Rollover enables VPN support for multiple CA certificates generated by third-party OPSEC-compliant CAs, such as Microsoft Windows CA. With multiple CA certificates, you can gradually rollover client and Security Gateway certificates during a transitional period when client and Security Gateway certificates signed by both CA certificates are recognized.

When a certificate is added to a CA that already has a certificate, the new certificate is defined as Additional and receives an index number higher by one than the highest existing certificate index number. The original certificate is defined as Main.

Only additional certificates can be removed. CA Certificate Rollover provides tools for adding and removing certificates, and for changing the status of a certificate from additional to main and from main to additional.

CA Certificate Rollover is for rolling over CA certificates with different keys. To add a CA certificate with the same key as the existing CA certificate (for example, to extend its expiration date), just Get the certificate from the OPSEC PKI tab of the CA properties, and do not use CA Certificate Rollover.

Managing a CA Certificate Rollover

With multiple CA certificates, you can gradually rollover client and Security Gateway certificates during a transitional period when client and Security Gateway certificates signed by both CA certificates are recognized.

This section describes a recommended workflow for the most common scenario. For full details of the CLI commands, see the "CA Certificate Rollover CLI" section.

Before you begin:

In SmartConsole, define a third-party OPSEC-compliant CA, such as Microsoft Windows CA, that is capable of generating multiple CA certificates. Generate the main CA certificate and define it in SmartConsole.

CA Certificate Rollover CLI

To perform CA Certificate Rollover use the VPN Multi-Certificate CA commands - mcc.

Adding Matching Criteria to the Validation Process

While certificates of an externally managed VPN entity are not handled by the local Security Management Server, you can still configure a peer to present a particular certificate when creating a VPN tunnel

CRL Cache Usage

Modifying the CRL Pre-Fetch Cache

Configuring CRL Grace Period

Configuring OCSP

To use OCSP, you must configure the CA object to use the OCSP revocation information method instead of the CRL method.

Use Database Tool (GuiDBEdit Tool) (see sk13009) to change the value of the field ocsp_validation to true. When set to true, the CA uses OCSP to make sure that certificates are valid. This is configured on the root CA and is inherited by the subordinate CAs.

To configure a CA to use OCSP, in Database Tool (GuiDBEdit Tool):

See sk37803 for detailed instructions.