Certificates are an important part of providing encryption services. They are used to identify and authenticate clients and gateways at the point when encrypted connections are established. This guidance describes how certificates should be initially provisioned, and how supporting infrastructure should be securely operated.
1. Approach
For most IPsec and TLS VPN connections, devices and gateways will need to use certificates based on a central trust infrastructure to successfully identify themselves to other devices. End entity X.509v3 certificates will need to be created for all authorised endpoints and registered with the trust infrastructure. The mechanism by which this is performed needs to ensure that unauthorised certificates cannot be registered, and that the centralised infrastructure remains trustworthy.
The trust infrastructure (usually referred to as a PKI – Public Key Infrastructure) is generally operated by the organisation which provides the encryption service. The local PKI may have trust relationships with other PKIs from other service providers and networks to allow encrypted connections to be made between devices under the control of different organisations.
PKIs are attractive targets for attackers. The information they hold (specifically private keys) and the function they perform (provision of trust) mean that a failure of security within a PKI can have far reaching and hard-to-detect consequences. For this reason, PKIs need to be well-protected against would-be attackers. Consequently:
- We strongly recommend that PKIs are not shared across communities who would have significantly different security expectations or operational considerations (such as sharing a PKI used for commercial entities with public sector organisations).
- The possible use of the PKI for different types of services (IPsec, TLS, S/MIME etc.) should be considered at the design stage. We suggest that separate sub CAs are used per technology function to prevent the malicious use of a compromised certificate across different services. Alternative approaches, such as the use of separate Certificate Policy OID (CPOID) values, key usage, and extended key usage fields, could also be used.
- We do not recommend using Pre-Shared Keys (PSKs), Group Domain of Interpretation (GDOI), and other approaches for establishing shared keys across end devices.
- All devices should ensure the certificates they are relying on are valid. This should be achieved by ensuring they have access to, and use, mechanisms for checking the status of certificates within the PKI – such as Certificate Revocation Lists (CRLs) or via Online Certificate Status Protocol (OCSP).
- Devices should be configured to check the entire certificate chain for validity, the end entity certificate, any sub CA certificates, and the root certificate. We recommend that PKI hierarchies are no more than three layers deep.
2. Managing certificates
End entity certificates will be X.509v3 certificates with the appropriate cryptographic elements for the selected IPsec or TLS profile.
- Certificates should be generated by an administrator on the device where they will be used, unless the relevant Security Procedures for that device recommend alternative generation processes.
- Private keys for certificates should never leave the device on which they are being used operationally.
- End entity certificates should be valid for one year, or for the expected life of the device on the network (whichever is shorter).
Certificates supporting single/low numbers of links
In the situation where a very limited number of VPN endpoints need to establish links (such as in the case of a long-lived data centre to data centre link, or for peering arrangements between network service providers), then establishing a PKI may represent an unnecessary overhead, and may not be required. Instead, all participating devices can have the relevant public keys for other participating VPN devices installed onto them.
It is important that the integrity and authenticity of these public values is maintained. If an attacker can cause the wrong keys to be installed, then they will be able to read information that should have been protected.
Certificates supporting multiple network links
For more complex networks a PKI will be required. The PKI provides a mechanism for each VPN endpoint to validate the identity of other endpoints, relying on a centrally provided set of services. The design, implementation and operation of a PKI is important, as these represent attractive targets for attackers. If a PKI can be coerced into registering devices that ought not to be, or disclosing private information (such as signing keys), then an attacker can compromise the security of the network.
An x509-based PKI will require a number of physical and logical components, including a Certificate Authority (CA), a Registration Authority (RA), a root of trust, and a means of revoking certificates. The organisation operating this PKI will also need to establish processes and procedures around these physical and logical components.
For the majority of scenarios where a PKI is required to support the identification of end entity cryptographic devices, the use of the PKI will be restricted to within a single relying organisation. In such circumstances, the organisation needs to ensure that the processes and technology used are appropriately secured by following these key points:
-
Implement an ‘offline root’ model, in which the root of the PKI is kept permanently disconnected from the network, and powered off, until it is required.
-
Establish well-defined processes for enrolling and revoking devices into and out of the PKI. These should map to associated business activities to ensure that only those endpoints which are expected to form part of the trusted infrastructure actually have valid certificates, and that all activities associated with the PKI are authorised and audited.
The key lifetimes for the root and sub CA(s) should be set to the anticipated life of the network, or the following dates (whichever are sooner). We will review the dates in the table below and update them as necessary.
| Item | Expiry Date |
| Sub CA lifetime | 31st Dec 2022 |
| Root CA lifetime | 31st Dec 2030 |
If multiple organisations will rely on the certificates issued by a Certification Authority then a Certificate Policy (CP) and Certification Practice Statement (CPS) will need to be produced and made available to all parties:
- the CP describes the overarching policy for the PKI
- the CPS describes the processes and practices that a CA follows to meet the CP when issuing certificates, and allows others to judge whether these processes and practices are appropriate to rely on; organisations should use RFC3647 as a template for their CPS
3. CP/CPS requirements
It is the responsibility of the PKI provider to define the CP and CPS, and the various permitted attributes of the root, sub CA, and end entity certificates. We recommend the following are included in a CP/CPS:
- Appropriate certificate usage: end entity certificates shall only be used for establishing encrypted links between endpoints within and between organisations.
- Certificate Revocation Lists (CRLs) must be accessible by all endpoints which are using certificates.
- Each CRL must contain a full and complete listing of all unexpired certificates issued by the CA that have been revoked.
- CRLs for end entity certificates must be published at least every 24 hours, with a recommended validity period of 192 hours (8 days, to avoid collisions with bank holidays). The root CA should publish a root CRL at least once a year.
- Sub CA certificates should contain one or more CRL Distribution Points (CDPs), containing the root CA CRL URIs.
- Each certificate issued must have a non-null X.501 Distinguished Name in the certificate ‘subject’ name field, in accordance with RFC5280. This must uniquely and unambiguously identify the device within the PKI.
- Values used in certificates must be assumed to be public information, and thought should therefore be given to the naming convention to ensure it does not accidentally include any sensitive or personal information.
- Anyone enrolling a device into the PKI must demonstrate that they have access to the private key corresponding to the public key contained in the certificate; this is generally achieved by signing the request.
- Prior to issuing or reissuing a certificate, the RA or CA will verify that the signature on the request is valid, and that the request is authorised.
- Certificates will only be requested and used on end entity devices that are used as part of the network.
- All certificate requests will be linked to a business process to ensure that only appropriate and expected devices are issued / reissued certificates.
- Information on any cross-certification with other Certificate Authorities shall be made available to relying parties.
- If any certificate has expired, been compromised or suspected of compromise, then routine re-keying should not occur.
- If any information contained in the certificate changes, then such alterations should be authenticated in the same manner as the initial registration.
- If a certificate has been compromised (or there is a reasonable suspicion of compromise) then it shall be immediately revoked.
- A CA must ensure a separation of duties, and where necessary use dual control, for critical CA functions to prevent one person from maliciously using the CA system without detection.
- Each user’s access is to be limited to those actions for which they are required to perform in fulfilling their defined responsibilities.
- An individual shall be identified who is responsible for the secure ongoing operation of the shared PKI service.
- PKI services should be subject to a well-scoped penetration test by competent individuals. The scope of this test shall include both internal and external attacks and application-layer testing.
- CA and RA private keys for PKIs shall be kept in secure facilities, with appropriate access controls enabling only authorised individuals to enter and access.
- CA and RA private keys for PKIs should be generated using a mechanism or product approved for such purpose by the NCSC.
4. Shared PKI services
There are situations where it is useful for multiple organisations to use a single shared PKI service. This service might be operated by one of the organisations on behalf of a wider community, or be provided by a commercial supplier for the purpose of supporting a community of VPN links. Where this is the case, the following points relating to the central PKI infrastructure should be implemented by the PKI provider if their PKI is to be shared across multiple organisations.
Providers offering PKI services to multiple customers may wish to independently demonstrate that their processes achieve the principles outlined in their Certificate Policy and have been implemented as described in their Certificate Practice Statement, through use of approaches such as tScheme.
a. Data-in-transit protection
Application-layer protection should be used to protect the integrity and authenticate requests and responses from the PKI service. Private keys should never be exchanged over such links, and certificates should always be authenticated, either using established points of trust, or via out-of-band mechanisms. For more information see Cloud Security Principles.
b. Asset protection and resilience
Users of the PKI service should have confidence that their data, and the assets storing or processing it, will be protected against physical tampering, loss, damage or seizure.
In practice, this means:
- Organisations using the PKI should be provided with information on where their data will be stored, processed and managed from.
- The physical security of locations providing the PKI service should be independently validated via CSA CCM v3.0, ISO/IEC 27001 or SSAE-16 / ISAE 3402.
- The PKI service provider’s procedures for physical security of media should be independently validated via CSA CCM v3.0, ISO/IEC 27001 or SSAE-16 / ISAE 3402.
- Components within the service provider’s architecture performing security-enforcing functions should be validated to Foundation Grade where available.
- Assured products should be used to perform sanitisation of media containing user information before disposal.
c. Separation between customers of the PKI service
Logical separation between different customers of the PKI should be designed and implemented to prevent a single malicious or compromised customer of the PKI service from affecting the service or data of another.
Network and logical access to the PKI service should be restricted to only those organisations and individuals with a business requirement to use it.
A skilled security architect (such as someone with CCP-certified ‘IA Architect’ at Senior or Lead level) should be involved. This will ensure that the architecture defends against common attacks, has appropriate security controls, and allows effective secure operation of the PKI service.
d. Governance framework
The PKI service provider should have a security governance framework that coordinates and directs their overall approach to the management of the PKI and information within it.
In practice, this means:
- There must be a clearly identified, and named, board representative (or a person with the direct delegated authority) who is responsible for the security of the PKI service. This is typically someone with the title of Chief Security Officer, Chief Information Officer or Chief Technical Officer.
- A documented framework must exist for security governance, with policies governing key aspects of information security relating to the PKI.
- Security and information security should form part of the service provider’s financial and operational risk reporting mechanisms.
- Processes exist to identify and ensure compliance with applicable legal and regulatory requirements relating to the PKI.
e. Operational security
The PKI service provider should have processes and procedures in place to ensure the operational security of the PKI. The PKI will need to be operated and managed securely in order to impede, detect or prevent attacks against it.
In practice, this means:
- The status, location and configuration of service components (including hardware and software components) are tracked throughout their lifetime within the PKI.
- Changes to the PKI are assessed for potential security impact. Changes are managed and tracked through to completion.
- Relevant sources of information relating to threat, vulnerability and exploitation technique information are monitored by the PKI provider.
- Known vulnerabilities within the PKI are tracked until sufficient mitigations have been deployed through a suitable change management process.
- ‘Critical’ patches should be deployed within 14 calendar days of a patch becoming available; ‘important’ patches should be deployed within 30 calendar days.
- Events generated in PKI components required to support effective identification of suspicious activity are collected and fed into an analysis system.
- Incident management processes are in place for the PKI and are enacted in response to security incidents. These should be validated using one of ISO/IEC 27035:2011, CSA CCM v3.0, or ISO/IEC 27001.
f. Supply chain security
PKI service providers often rely on third party products and services. Those third parties can have an impact on the overall security of the PKI service. The service provider should ensure that any third parties that it relies on to securely provide its PKI service (such as a hosting service) also meet relevant security principles from this document to an appropriate level.
g. Identity and authentication
Consumer and service provider access to all PKI interfaces should be constrained to authenticated and authorised individuals. Weak authentication or access control may allow unauthorised changes to the PKI, leading to theft or modification of data, or denial of service. It is also important that authentication occurs over secure channels. Use of insecure channels such as email, HTTP or telephone can be more vulnerable to interception or social engineering attacks.
h. External interface protection
All external or less trusted interfaces of the PKI service should be identified and have appropriate protections to defend against attacks through them. If an interface is exposed to PKI consumers or outsiders and it is not sufficiently robust, then it could be subverted by attackers in order to gain access to the PKI or data within it. If the interfaces exposed include private interfaces (such as management interfaces) then the impact may be more significant.
i. Audit and monitoring
The PKI service provider should ensure that all activities which:
- cause the set of certificates issued by the CA to change (eg addition, deletion, alteration), or
- otherwise affect the secure operation of the PKI
shall be audited in such a manner as to ensure traceability of action, identified individual, and, where applicable, business process.
Access to the audit log shall be read only by appropriately authorised individuals. Auditing mechanisms shall be designed to protect the integrity of the audit information after creation so that a failure or compromise does not directly compromise previous audit information.
Source: NCSC
