Public Key Infrastructure (PKI)

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 GatewayClosed 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 ServerClosed 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 (ICAClosed 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 ServerClosed 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 Internal Certificate Authorities.

  • 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.

The Check Point Suite supports certificates not only for Security Gateways but for Remote Access VPNClosed An encrypted tunnel between remote access clients (such as Endpoint Security VPN) and a Security Gateway. users as well.

For more information, see the R82 Remote Access VPN Administration Guide.

Following are some sample Certificate Authority deployments:

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.

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".

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.

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 Certificate Authority (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 R82 Security Management Administration Guide.

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

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 R82 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. Online Certificate Status Protocol (OCSP)

  2. CRL

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.

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

See Configuring OCSP.

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.

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.

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:

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.

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 BladeClosed 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 ClusterClosed 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.

To create a PKCS#10 Certificate Request:

  1. Create a Certificate Authority object.

  2. From the left navigation panel, click Gateways & Servers.

  3. Double-click the applicable Security Gateway or Cluster object.

  4. From the left tree, click General Properties and make sure to enable the IPsec VPN Software Blade.

  5. From the left tree, click IPsec VPN.

  6. In the section Repository of Certificates Available to the Gateway, click Add.

    The Certificate Properties window opens.

  7. In the Certificate Nickname field, enter a text string.

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

  8. From the drop-down menu CA to enroll from, select the Certificate Authority that issues the certificate.

    Note - The menu shows only trusted Certificate Authorities and subordinate Certificate Authorities that lead directly to a trusted Certificate Authority. 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.

  9. In the section Key pair generation and storage, select the applicable method:

    • Store keys on the Security Management server - Certificate creation is performed entirely between the Management Server and applicable CA. The keys and the certificate are downloaded securely to the Security Gateway (Cluster Members) during policy installation.

    • Store keys on the Module - Management Server directs the Security Gateway (or Cluster Members) to create the keys and supply only the required material for creation of the certificate request. Only the certificate is downloaded to the Security Gateway (Cluster Members) during policy installation.

  10. Click Generate.

    The Generate Certificate Properties window opens.

  11. Enter the applicable DN.

    The CA administrator determines the final DN that appears in the certificate.

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

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

    Note - Adding the object's IP address as the Alternate Name extension can be configured as a default setting.

    This configuration also applies for Internal Certificate Authorities.

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

    2. Click Certificates and PKI properties.

    3. Select these options:

      • add_ip_alt_name_for_ICA_certs (closer to the top of this page)

      • add_ip_alt_name_for_opsec_certs (closer to the bottom of this page)

    4. Click OK to close the Advanced Configuration window.

    5. Click OK to close the Global properties window.

  12. When the certificate appears in the section Repository of Certificates Available to the Gateway:

    1. Select this certificate.

    2. Click View.

    3. In the Certificate View window:

      1. Click inside the window.

      2. Select the whole text (press the CTRL+A keys, or right-click the mouse and click Select All).

      3. Copy the whole text (press the CTRL+C keys, or right-click the mouse and click Copy).

      4. Paste the text into a plain text editor (like Notepad).

      5. Click OK.

  13. Send the certificate information to the Certificate Authority administrator.

    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.

  14. After the certificate arrives from the Certificate Authority administrator, you must save it in the Certificate Authority object:

    1. In SmartConsole, click Objects > Object Explorer (or press the CTRL+E keys).

    2. In the left tree, click Servers.

    3. Double-click the applicable Certificate Authority object.

    4. Click the OPEC PKI tab.

    5. In the Certificate section, click Get.

    6. Browse to the location, where you saved the certificate file.

    7. Select the certificate file and click Open.

    8. If the certificate details are correct, click OK to accept this certificate.

    9. Click OK to close the Certificate Authority Properties window.

    10. Close the Object Explorer window.

  15. Publish the SmartConsole session

On the OPSEC PKI tab of the Certificate Authority object:

  1. Select the option Automatically enroll certificate.

  2. Select the applicable protocol - scep or cmp.

Follow these steps:

  1. From the left navigation panel, click Gateways & Servers.

  2. Double-click the applicable Security Gateway or Cluster object.

  3. From the left tree, click General Properties and make sure to enable the IPsec VPN Software Blade.

  4. From the left tree, click IPsec VPN.

  5. In the section Repository of Certificates Available to the Gateway, click Add.

    The Certificate Properties window opens.

  6. In the Certificate Nickname field, enter a text string.

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

  7. From the drop-down menu CA to enroll from, select the Certificate Authority 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.

  8. In the section Key pair generation and storage, select the applicable method:

    • Store keys on the Security Management server - Certificate creation is performed entirely between the Management Server and applicable CA. The keys and the certificate are downloaded securely to the Security Gateway (Cluster Members) during policy installation.

    • Store keys on the Module - Management Server directs the Security Gateway (or Cluster Members) to create the keys and supply only the required material for creation of the certificate request. Only the certificate is downloaded to the Security Gateway (Cluster Members) during policy installation.

  9. 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.

  10. When the certificate appears in the section Repository of Certificates Available to the Gateway:

    1. Select this certificate.

    2. Click View.

    3. In the Certificate View window, click Copy to Clipboard or Save to File.

  11. 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 by email. After you receive the certificate, save it to disk.

  12. From the left tree click, IPsec VPN.

  13. In the section Repository of Certificates Available to the Gateway:

    1. Select the applicable certificate.

    2. Click Complete.

  14. Browse to the folder where you stored the issued certificate, select the certificate, and examine the certificate details.

  15. Click OK to close the Security Gateway or Cluster object.

  16. Publish the SmartConsole session

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.

Special Considerations for PKI

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 (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. In the left panel, 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

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

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 R82 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.

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.

To remove the certificate:

  1. From the left navigation panel, click Gateways & Servers..

  2. Double-click the Security Gateway / Cluster object.

  3. In the left panel, click IPsec VPN.

  4. In the Repository of Certificates Available to the Gateway, select the applicable certificate and click Remove.

  5. Click OK.

  6. Install the Access Control policy.

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

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:

  1. From the left navigation panel, click Gateways & Servers..

  2. Double-click the Security Gateway / Cluster object.

  3. In the left panel, click IPsec VPN.

  4. In the Repository of Certificates Available to the Gateway, select the applicable certificate and click Renew.

  5. Click OK.

  6. Install the Access Control policy.

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

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.

  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. Connect to the command line on the Security Management Server.

  3. Log in to the Expert mode.

  4. Add the new CA certificate to the Security Management Server database's definitions for the third-party CA:

    mcc add <CA Name> <Certificate File>

    See mcc add:

    • <CA Name> is the name of the CA as defined in the Security Management Server database.

    • <Certificate File> is the certificate filename or path.

  5. The new CA certificate should now be defined as additional #1.

    Make sure with the mcc lca or mcc show command.

  6. In SmartConsole, install the Access Control Policy on all Security Gateways.

Use the new additional CA certificate to sign client certificates.

For performance reasons, as long as most clients still use 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.

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

  1. Open the VPN page of the externally managed VPN entity.

  2. Click Matching Criteria.

  3. Choose the 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

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 Security Gateway.

    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.

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

  2. Click Certificates and PKI properties.

  3. In the prefetch_crls_duration field, configure the duration.

  4. Click OK.

  5. Install the Access Control Policy.

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

  2. In the CRL Grace Period section, configure the applicable times.

  3. Click OK.

  4. Install the Access Control Policy.

The Grace Period can be defined for both the periods before and after the specified CRL validity 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) 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.