Define additional VPN certificate authorities

To use certificates that are signed by an external CA, define an additional VPN certificate authorities.

Before you begin

You must have the root certificate (or a valid certificate) from the certificate authority (CA).

Note: Only the Internal RSA CA for Gateways and Internal ECDSA CA for Gateways of your SMC are configured as trusted CAs for gateways in VPNs by default. The Internal RSA CA for Gateways is automatically created when you install the SMC.

You can configure the CA as trusted by importing its root certificate or a valid certificate signed by the CA. The certificates must be X.509 certificates in PEM format (Base64 encoding). It might be possible to convert between formats using, for example, OpenSSL or the certificate tools included in Windows.

Important:
Below are the requirements for a root certificate:
  • The following types of authentication key are only accepted:
    • For Common Criteria evaluated configuration:
      • RSA-2048
      • RSA-2072
      • RSA-4096
      • ECDSA P-256
      • ECDSA P-384
      • ECDSA P-521
    • For Commercial Solutions for Classified configuration:
      • RSA-3072
      • RSA-4096
      • ECDSA P-384
  • The digest algorithm must be one of the following:
    • For Common Criteria evaluated configuration:
      • SHA-1
      • SHA-256
      • SHA-384
      • SHA-512
    • For Commercial Solutions for Classified configuration:
      • SHA-384
      • SHA-512
  • All the certificates in the chain that is signed by the root certificate must have either a Certificate Revocation List (CRL) distribution point, or an Online Certificate Status Protocol (OCSP) server URL, or both. Additionally, OCSP or CRL checking must be enabled in the root CA settings.

The CAs you use can be either private (for self-signed certificates) or public (commercial certificate issuers). When you define a CA as trusted, all certificates signed by that CA are valid until their expiration date (or until the CA certificate expires). Optionally, you can also set up the Security Engine to check the certificate revocation status from certificate revocation lists (CRLs) or through the OCSP protocol. The CA can cancel a certificate, for example, because it is compromised.

Forcepoint Network Security Platform supports OCSP and CRL revocations for X.509v3 certificate validation during negotiation of IPsec VPN.

Forcepoint Network Security Platform constructs the certificate path to a trusted certificate, and then verifies the signature, checks the revocation status, validity period, issuer’s name, extended key usage and basic constraints for each certificate starting from the trusted certificate.

  • Revocation status checks using OCSP and CRLs can be enabled independently for each trusted CA.
  • The settings are applied to the whole certificate chain excluding the trust anchor.
  • When OCSP is enabled but the certificate is not bearing OCSP responder information, or Forcepoint Network Security Platform cannot establish a connection with the OCSP responder, revocation status cannot be determined using OCSP.
  • When CRLs are enabled but the certificate is not bearing CRL information, or Forcepoint Network Security Platform cannot establish a connection to the CRL Distribution Point location, revocation status cannot be determined using a CRL.
  • When both OCSP and CRLs are enabled but Forcepoint Network Security Platform cannot determine revocation status using OCSP, revocation status is checked using a CRL.
  • When either OCSP or CRLs are enabled and Forcepoint Network Security Platform cannot determine the revocation status, Forcepoint Network Security Platform will not accept the certificate as valid.

By default, all CAs you have defined are trusted by all gateways and in all VPNs. If necessary, you can limit trust to a subset of the defined CAs when you configure the VPN Gateway and VPN Profile elements. The trust relationships can be changed at the gateway level and in the VPN Profiles.

To obtain a certificate from an external certificate authority, first create a certificate request.

For more details about the product and how to configure features, click Help or press F1.

Steps

  1. Select Secure SD-WAN Configuration.
  2. Browse to Other Elements > VPN Certificates > VPN Certificate Authorities.
  3. Right-click VPN Certificate Authorities, then select New VPN Certificate Authority.
  4. On the General tab, configure the settings.
    Note: All fields but the Name on the General tab are grayed out. The grayed out fields are always filled in automatically based on information contained in the certificate you import. You cannot change the information in the grayed out fields. The information is shown when you close and reopen the VPN Certificate Authority element after importing the information.
    CAUTION:
    When certificate checking is defined, all certificates signed by the CA are treated as invalid if the validity check cannot be performed. For example, the validity check might not be performed due to incorrectly entered addresses or connectivity problems.
  5. On the Certificate tab, import the certificate in one of the following ways:
    • Click Import, then import a certificate file.
    • Copy and paste the information into the field. Include the “Begin Certificate” header and “End Certificate” footer in the information that you copy and paste.
    Tip: You can copy and paste the certificate information for many public certificate authorities from the default Trusted Certificate Authority elements. The default Trusted Certificate Authority elements are in the Configuration view under Administration > > Certificates > Certificate Authorities > Trusted Certificate Authorities.
  6. Select Check Validity on Certificate-Specified CRLs to validate the revocation status of the certificate using a Certificate Revocation List (CRL).
  7. Select Check Validity on Certificate-Specified OCSP Servers to validate the revocation status of the certificate using the Online Certificate Status Protocol (OCSP).
  8. Click OK.

Next steps

If you see an invalid certificate error, the certificate you imported might be in an unsupported format. Try converting the certificate to an X.509 certificate in PEM format (Base64 encoding) using OpenSSL or the certificate tools included in Windows.

If your Engine Policy is based on the Engine Template, both LDAP (port 389) and HTTP (port 80) connections from the Engine are allowed. If your Engine or server configuration differs from these standard definitions, edit the Engine Policy to allow the necessary connections from the Firewalls.