|
|
|
In This Section: |
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 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:
Check Point Security Gateways support many different scenarios for integrating PKI in VPN environments:
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.
Following are some sample CA 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:
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:
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.
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:
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 R80.30 Threat Prevention Administration Guide.
When an entity receives a certificate from another entity, it must:
In addition, VPN verifies the validity of the certificate's use in the given situation, confirming that:
There are two available methods useful in determining the status of a certificate:
A certificate is automatically issued by the ICA for all internally managed entities that are VPN capable. That is, after the administrator has checked selected IPsec VPN in the Network Security tab of the General Properties page for network objects.
The process for obtaining a certificate from an OPSEC PKI or External Check Point CA is identical.
To create a PKCS#10 Certificate Request:
The Certificate Properties window opens.
The nickname is only an identifier and has no bearing on the content of the certificate.
Note - The list shows only those subordinate CAs 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.
The Generate Certificate Properties window opens.
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, select Define Alternate Name.
Adding the object IP address as Alternate name extension can be configured as a default setting:
add_ip_alt_name_for_ICA_certs
add_ip_alt_name_for_opsec_certs
Note - The configuration in this step is also applicable for Internal CAs.
The public key and the DN are then used to DER-encode a PKCS#10 Certificate Request.
The Certificate Request View window appears with the encoding.
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. After the certificate has arrived, it needs to be stored:
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:
The Certificate Properties window opens.
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.
The Generate Keys and Get Automatic Enrollment Certificate window opens.
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.
When enrolling through a subordinate CA:
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.
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.
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:
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:
cprestart command, run the vpn crl_zap command to empty the cache, or:When a new policy is installed, the cache is flushed, and a new CRL will be retrieved on demand.
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.
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:
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.
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.
A VPN module automatically trusts the ICA of the Security Management Server that manages it. No further configuration is required.
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:
The Certificate Authority Properties window opens.
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.
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.
Then define the CA object according to the following steps:
The Certificate Authority Properties window opens.
Note - For entrust 5.0 and later, use CMPV1.
Note - If Automatic enrollment is not selected, then enrollment will have to be performed manually.
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 R80.30 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.
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.
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:
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 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 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 CA Certificate Rollover CLI.
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.
To roll over with a new CA certificate:
mcc add <CA> <CertificateFile>
<CA> is the name of the CA as defined in the Security Management Server database.<CertificateFile> is the certificate filename or path.mcc lca or mcc show command.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.
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:
To cancel or modify the behavior of the CRL Cache:
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.
See: CRL Prefetch-Cache for information about CRL caching.
To modify the duration of the Pre-fetch cache:
To configure the CRL Grace Period values:
The Grace Period can be defined for both the periods before and after the specified CRL validity period.
To use OCSP, you must configure the CA object to use the OCSP revocation information method instead of the CRL method.
Use 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 GuiDBedit Tool:
See sk37803 for detailed instructions.