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 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 gateway uses the peer Security Gateway's 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 includes an Internal Certificate Authority (ICA) 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. 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's 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 CA's 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 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 CA's 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's 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 R76 Security Management Server Administration Guide for further information
• An OPSEC Certified CA, use the CA options on the Servers and OSPEC 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 OSPEC 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 obtaining a certificate from a CA, that is, requesting that the CA issue a certificate 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 using 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

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 ICA for all internally managed entities that are VPN capable. That is, after the administrator has checked the VPN option in the Check Point Products area of a network objects General Properties tab.

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

Manual Enrollment with OPSEC Certified PKI

To create a PKCS#10 Certificate Request:

1. Create the CA object, as described in Trusting an OPSEC Certified CA.
2. Open the VPN tab of the relevant Network Object.
3. In the Certificate List field click Add...

   The Certificate Properties window is displayed.

4. Enter the Certificate Nickname

   The nickname is only an identifier and has no bearing on the content of the certificate.

5. From the CA to enroll from drop-down box, select the direct OPSEC CA/External CheckPoint CA that will issue the certificate.

   Note - The list displays only those subordinate CA's that lead directly to a trusted CA and the trusted CAs themselves. If the CA that issues the certificate is a subordinate CA that does not lead directly to a trusted CA, the subordinate CA will not appear in the list.

6. Choose the appropriate method for Key Pair creation and storage. See Distributed Key Management and Storage for more information.
7. Click Generate...

   The Generate Certificate Properties window is displayed.

8. Enter the appropriate DN.

   The final DN that appears in the certificate is decided by the CA administrator.

   If a Subject Alternate Name extension is required in the certificate, check the Define Alternate Name check box.

   Adding the object IP as Alternate name extension can be configured as a default setting by selecting in Global Properties > SmartDashboard Customization > Configure > Certificates and PKI properties, the options:

   add_ip_alt_name_for_opsec_certs

   add_ip_alt_name_for_ICA_certs

   The configuration in this step is also applicable for Internal CA's.

9. Click OK.

   The public key and the DN are then used to DER-encode a PKCS#10 Certificate Request.

10. Once the Certificate Request is ready, click View...

    The Certificate Request View window appears with the encoding.

11. Copy the whole text in the window and deliver it to the CA.

    The CA administrator must now complete the task of issuing the certificate. Different CAs provide different ways of doing this, such as an advanced enrollment form (as opposed to the regular form for users). The issued certificate may be delivered in various ways, for example email. Once the certificate has arrived, it needs to be stored:

    1. Go to the Severs and OPSEC Applications tab of the network object, select the appropriate CA object.
    2. Open the OPEC PKI tab, click Get... and browse to the location in which the certificate was saved.
    3. Select the appropriate file and verify the certificate details.
    4. Close object and save.

Automatic Enrollment with the Certificate Authority

On the OPSEC PKI tab of the CA object, make sure Automatically enroll certificate is selected and SCEP or CMP are chosen as the connecting protocol. Then:

1. On the relevant network object, open the VPN tab.
2. In the Certificates List section, click Add...

   The Certificate Properties window opens.

3. Enter a Certificate Nickname (any string used as an identifier)
4. From the drop-down menu, select the CA that issues the certificate.

   Note - The menu shows only trusted CAs and subordinate CAs that lead directly to a trusted CA. If the CA that issues the certificate is a subordinate CA that does not lead directly to a trusted CA, it is not in the menu.

5. Select a method for key pair generation and storage.
6. Click Generate, and select Automatic enrollment.

   The Generate Keys and Get Automatic Enrollment Certificate window opens.

   • Supply the Key Identifier and your secret authorization code.
   • Click OK.
7. When the certificate appears in the Certificates List on the network objects VPN page, click View and either Copy to Clipboard or Save to File the text in the Certificate Request View window.
8. Send the request to CA administrator.

   Different Certificate Authorities provide different means for doing this, for example an advanced enrollment form on their website. The issued certificate can be delivered in various ways, such as email. Once you have received the certificate, save it to disk.

9. On the VPN tab of the network object, select the appropriate certificate in the Certificates List, and click Complete...
10. Browse to the folder where you stored the issued certificate, select the certificate and verify the certificate details.
11. Close the network object and Save.

Enrolling through a Subordinate CA

When enrolling through a subordinate CA:

• Supply the password of the subordinate CA which issues the certificate, not the CA at the top of the hierarchy
• The subordinate CA must lead directly to a trusted CA

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 CA's.

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.

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 cancelled, 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, 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 cpstop, cpstart the CRL's will be updated immediately, proceed as follows:

• After executing cprestart, run crl_zap to empty the cache, or:
• In Global Properties > SmartDashboard Customization > Configure > Check Point CA properties > select: flush_crl_cache_file_on_install.

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 CLR 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, and can be configured as a default setting by selecting in Global Properties > SmartDashboard Customization > Configure > Certificates and PKI properties, the option: use_dkm_cert_by_default

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 refers to the ICA of another Security Management server. The CA certificate has to be supplied and saved to disk in advance. To establish trust:

1. Open Manage > Servers and OPSEC Applications

   The Servers and OPSEC Application window opens.

2. Choose New > CA

   Select Trusted...

   The Certificate Authority Properties window opens.

3. Enter a Name for the CA object and in the Certificate Authority Type drop-down box select the External Check Point CA.
4. Go to the External Check Point CA tab and click Get...
5. Browse to where you saved the peer CA certificate and select it.

   VPN reads the certificate and displays its details. Verify the certificate's details. Display and validate the SHA-1 and MD5 fingerprints of the CA certificate.

6. Click OK.

Trusting an OPSEC Certified CA

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

The CA's Certificate must be retrieved either by downloading it using the CA options on the Servers and OSPEC Applications tab, or by obtaining the CA's certificate from the peer administrator in advance.

Then define the CA object according to the following steps:

1. Open Manage > Servers and OPSEC Applications.

   The Servers and OPSEC Application window opens.

2. Choose New > CA.

   Select Trusted or Subordinate.

   The Certificate Authority Properties window opens.

3. Enter a Name for the CA object, in the Certificate Authority Type drop-down box select the OPSEC PKI.
4. 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

5. 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 appropriate 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.

6. 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 Security Management Server Administration Guide for more details about defining an LDAP object.

   Make sure that CRL retrieval is checked in the General tab of the LDAP Account Unit Properties window.

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

7. Click Get.
8. 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.

   VPN reads the certificate and displays its details. Verify the certificate's details. Display and validate the SHA-1 and MD5 fingerprints of the CA certificate.

9. 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, certificate revocation is controlled by the CA administrator using the options on the Advanced tab of the CA object. In addition, the certificate must be removed from the module.

To remove the certificate:

1. Open the VPN tab of the relevant Network Object.
2. In the Certificate List field select the appropriate certificate and click Remove.

   A certificate cannot be removed if Smart Center server infers from other settings that the certificate is in use, for example, that the module belongs to one or more VPN communities and this is the module's only certificate.

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.

CA Certificate Rollover

CA Certificate Rollover is a VPN-1 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-1 support for multiple CA certificates generated by third-party OPSEC-compliant CAs, such as Microsoft Windows CA. By using 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 using 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

By using 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 CA Certificate Rollover CLI.

Before you begin:

In SmartDashboard, 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 SmartDashboard.

To roll over with a new CA certificate:

1. Generate from the third-party CA a second CA certificate in DER format (PEM is not supported), with different keys than the previous CA certificate. Copy the certificate to the Security Management Server.
2. Log into the Security Management Server, and stop Check Point processes:
   cpstop
3. Back up the Security Management Server database:
   vpn mcc backup
4. Add the new CA certificate to the Security Management Server database’s definitions for the third-party CA:
   vpn mcc add <CA> <CertificateFile>
5. <CA> is the name of the CA as defined in the Security Management Server database. <CertificateFile> is the certificate filename or path.
6. The new CA certificate should now be defined as additional #1. Make sure with "vpn mcc lca” or “vpn mcc show”.
7. Start Check Point processes:
   cpstart
8. Install policy on all Security Gateways.

Use the new additional CA certificate to sign client certificates.

For performance reasons, as long as most clients are still using certificates signed by the old CA certificate, you should leave the new CA certificate as the additional one and the old certificate as the main one. As long as the new CA certificate is not the main CA certificate, do not use it to sign any Security Gateway certificates.

CA Certificate Rollover CLI

CA Certificate Rollover uses the VPN Multi-Certificate CA command set, as detailed in this section. VPN Multi-Certificate CA configuration commands should not be run when SmartDashboard or Database Tool are logged in to the Security Management Server, or when Check Point processes are running.

To see usage instructions in the CLI, run the following without arguments:

vpn 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:

1. Open the VPN page of the externally managed VPN entity.
2. Click Matching Criteria...
3. Choose the desired characteristics of the certificate the peer is expected to present, including:
   • The CA that issued it
   • The exact DN of the certificate
   • The IP address that appears in the Subject Alternate Name extension of the certificate. (This IP address is compared to the IP address of the VPN peer itself as it appears to the VPN module during the IKE negotiation.)
   • The e-mail address appearing in the Subject Alternate Name extension of the certificate

CRL Cache Usage

To cancel or modify the behavior of the CRL Cache:

1. Open the Advanced Tab of the Certificate Authority object.
2. To enable the CRL cache, check Cache CRL on the module.

   The cache should not be disabled for the ICA. In general, it is recommended that the cache be enabled for all CA types. The cache should be disabled (for non-ICAs) only if stringent security requirements mandate continual retrieval of the CRL.

   Note - The ICA requires the use of a CRL cache, and should never be disabled.

3. If CRL Cache is enabled, choose whether a CRL is deleted from the cache when it expires or after a fixed period of time (unless it expires first). The second option encourages retrieval of a CRL more often as CRLs may be issued more frequently than the expiry time. By default a CRL is deleted from the cache after 24 hours.

See: CRL Prefetch-Cache for information about CRL caching.

Modifying the CRL Pre-Fetch Cache

The behavior of the Pre-fetch catch can be altered via the Global properties:

1. Global Properties > SmartDashboard Customization > Configure... button

   The Advanced Configuration window opens.

2. Select Check Point CA Properties:

Configuring CRL Grace Period

Set the CRL Grace Period values by selecting Policy > Global Properties > VPN > Advanced. The Grace Period can be defined for both the periods before and after the specified CRL validity period.

Configuring OCSP

To use OCSP, the CA object must be configured to the OCSP revocation checking method instead of CRL's.

Using dbedit or GuiDBedit, modify the field ocsp_validation to true. Set to true, this CA will check the validation of the certificate using OCSP. This is configured on the root CA and is inherited by the subordinate CA's.

To configure a trusted OCSP server using dbedit for objectc.c:

1. Create a new server object of the type ocsp_server.
2. Configure the OCSP servers URL and the certificate.
3. In the CA object, configure ocsp_server. Add a reference to the OCSP server object created and install policy.