VPN certificates and how they work

Certificates can be used for authenticating VPN gateways and the Stonesoft VPN Client.

In site-to-site VPNs, you can use both pre-shared keys and certificates as the authentication method. In mobile VPNs, certificates are always needed when the Stonesoft VPN Client is involved. However, if you use the hybrid authentication method with the Stonesoft VPN Client, only the gateway needs a certificate.

What VPN certificates do

Certificates do not contain information that is specific to a particular VPN. You can use certificates for authentication in both the policy-based and route-based VPNs. A certificate authority (CA) issues certificates as proof of identity. Gateways that form a VPN tunnel are configured to trust the CA that signed the other gateway’s certificate. All certificates issued by a trusted CA are accepted as valid, so certificates can be added, renewed, and changed without affecting the VPN as long as the actual identity information is correct. The same certificate can be used for any number of VPNs with any number of gateways and VPN clients.

Certificates are always required for gateways to which the Stonesoft VPN Client connects. Certificates can optionally be used to identify VPN clients, but are not mandatory.

Certificates reduce the required maintenance work, because they do not have to be changed as frequently as pre-shared keys. All certificates are created with an expiration date, after which the certificate is no longer valid. Certificates signed by an Internal RSA CA for Gateways or an Internal ECDSA CA for Gateways are valid for three years from their creation. When a certificate expires, a new certificate is needed.

Certificate management

Certificate-related tasks in the SMC mostly involve VPN Gateways that represent firewalls. VPN certificates can be generated by any internal or external certificate authorities that both gateways are configured to trust. There are several options for signing VPN Gateway certificates:

  • The Management Server includes a dedicated Internal RSA CA for Gateways and optionally an Internal ECDSA CA for Gateways for signing VPN certificates. You use these certificate authorities through the Management Client.
  • One Internal CA for Gateways can be selected as the default CA. Certificate management can be automatic if the certificate is signed using the Management Server’s internal default CA.
  • You can create certificate requests in the Management Client, export them, sign them using an external CA, and then import the signed certificate back into the SMC.

RSA certificates can be created and renewed automatically using the default CA. Some manual steps are required in the following cases:

  • You have both an Internal RSA CA for Gateways and an Internal ECDSA CA for Gateways. Only one Internal CA for Gateways can be selected as the default certificate authority. You must manually create and renew any certificates that are not signed by the default CA.
  • You use DSA certificates.
  • You want to use an external CA to sign certificates.

The Internal RSA CA for Gateways or Internal ECDSA CA for Gateways can also sign certificate requests created by external components. This feature is meant to support VPN client deployments. If you have used the Internal RSA CA for Gateways or Internal ECDSA CA for Gateways to sign certificate requests, you cannot cancel the issued certificates. Consider how widely you can use them for signing external certificate requests within your organization.

Limitations

  • All gateways in the same VPN must support the same CA algorithm. Otherwise, VPN communication fails. For example, if you use an Internal ECDSA CA for Gateways as the default CA, all other gateways used in the same VPN must support ECDSA.
  • Certificates created for VPN gateways for establishing the VPN are stored on the VPN gateway devices (Firewalls). These certificates are not included in the Management Server backup, and are not changed in any way when a Management Server backup is restored.
  • Certificates can become unusable if the private key for that certificate is lost. The key can be lost, for example, if the NGFW Engine hardware fails and must be replaced. Firewall Clusters share each VPN certificate and can synchronize the private key from node-to-node as needed. If the private key is erased from a Single Firewall or from all the nodes of a Firewall Cluster, a new certificate must be created.
  • Externally issued VPN certificates can be revoked by the certificate authority that issued them. This safety measure is used when the certificate is suspected to be compromised.