Skip to Content

How to meet the requirements for FSBP SH04.2 in the Security Rating Report (‘IPsec tunnels should be using valid and secure certificates’)

This article describes Fortinet Security Best Practices (FSBP) SH04.2, which recommends that ‘IPsec tunnels should be using valid and secure certificates’. This article also describes some of the conditions that are being checked, as well as how to satisfy this requirement.

Scope

FortiGate.

Solution

The above FSBP requirement is triggered for review by the Security Rating Report if an administrator configures an IPsec VPN tunnel to use Signature-based (aka certificate) authentication, rather than a Pre-Shared Key for authentication to the IPsec peer.

See the following documentation for examples of such scenarios:

  • Site-to-site VPN with digital certificate
  • Dialup IPsec VPN with certificate authentication

If no such tunnel is created (i.e. no tunnel uses certificate-based authentication), then the FortiGate automatically meets the requirement.

If there are tunnels configured with certificate-based authentication then the following are some of the conditions that will be checked:

‘Must be using at least 2048 bit RSA.’.

  • FSBP SH04.2 will be marked as a failure if the certificate is using an insecure/weak protocol for the public/private key pair.
  • As an example, certificates with RSA1024 would fail this requirement (insufficient key length/complexity), as would certs with DSA2048 (DSA being deprecated as of NIST FIPS 186.5, for example).
  • Notably, Elliptic Curve-based certificates will satisfy this requirement, even if they technically have a shorter key length than 2048 (elliptic-curve cryptography generally allows smaller keys that provide equivalent security to RSA-based systems).

‘Must not be expired, the certificate expired on <VPN name>.’.

  • The certificate must have a Validity period that is still valid for the current date (i.e. its Valid To/Not After field must be a date that is still in the future). If the certificate is expired then it is no longer valid (this is true for all situations that utilize certificates for authentication, such as with TLS-encrypted web servers).

‘Must not be a built-in default certificate. Acquire a certificate for your domain, upload it, and use it.’

  • The FortiGate is equipped with several default certificates that can be used. However, while they are fine from a TLS encryption standpoint, they will not be valid for proper chain-of-trust authentication.
  • This is fully expected and normal: the certificates will lack Common Names/Subject Alternative Names that are appropriate for end-user use, and they are also signed by a private Fortinet Certificate Authority that is not recognized by public lists of Root /Intermediate Certificate Authorities (i.e. the web browser will not trust the CA or these certificates by default).
  • It is better to purchase or generate proper certificates signed by trusted Certificate Authorities (either commercial entities like DigiCert or by private Certificate Authorities that are under personal control).
  • It is also possible to use Let’s Encrypt to acquire a free certificate, which is something that the Security Rating recommendations include: ‘Let’s Encrypt can be used to easily generate a trusted certificate if you do not have one. To do this simply import a new local certificate and select type ‘Automated’.’.

‘The certificate appears to be invalid. It is recommended that a different certificate is used.’

  • There may be a general issue that is affecting the validity of the certificate. Check to see if there are identifiable issues with the certificate itself, then try switching to another certificate. It is also possible to try regenerating/reimporting the current certificate.