Provisioning and securing security certificates

For most IPsec and TLS VPN connections, devices and gateways must utilize certificates from a centralized trust infrastructure to effectively identify themselves to other devices. It is crucial to create end entity X.509v3 certificates for all authorized endpoints and register them with the trust infrastructure. This mechanism must prevent unauthorized certificates from being registered, ensuring that the central infrastructure remains reliable.

The trust infrastructure, commonly known as a Public Key Infrastructure (PKI), is typically managed by the organization offering the encryption service. The local PKI may establish trust relationships with other PKIs from different service providers to enable encrypted connections among devices managed by various organizations.

PKIs are appealing targets for malicious actors, as they hold crucial information (especially private keys) and provide trust functions. Any security breach within a PKI can result in widespread and difficult-to-detect consequences. Therefore, it is crucial for PKIs to have robust defenses against potential attackers. Hence:

• We strongly advise against sharing PKIs across communities with significantly different security requirements or operational considerations (e.g., using a PKI for commercial entities alongside public sector organizations).
• Consider the potential use of the PKI for various services (IPsec, TLS, S/MIME, etc.) during the design phase. We recommend utilizing separate subordinate Certificate Authorities (CAs) per technology function to mitigate the risk of a compromised certificate being exploited across different services. Alternative methods, such as using different Certificate Policy OID (CPOID) values, key usage, and extended key usage fields, can also be applied.
• We do not endorse the use of Pre-Shared Keys (PSKs), Group Domain of Interpretation (GDOI), or similar methods for establishing shared keys among end devices.
• All devices must verify that the certificates they depend on are valid. This can be accomplished by ensuring access to and utilization of mechanisms to check certificate status within the PKI, such as Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).
• Devices should be configured to verify the entire certificate chain for validity, including the end entity certificate, any subordinate CA certificates, and the root certificate. We recommend that the PKI hierarchy does not exceed three layers deep.

End entity certificates will be X.509v3 certificates that include the necessary cryptographic components for the chosen IPsec or TLS profile.

• Certificates should be generated by an administrator on the device where they will be utilized, unless the relevant Security Procedures for that device dictate otherwise.
• Private keys for certificates must remain on the device where they are operationally used.
• End entity certificates should be valid for up to one year or for the anticipated lifespan of the device on the network, whichever is shorter.

Certificates for Single/Low Link Numbers

In scenarios where only a small number of VPN endpoints need to establish connections (such as a long-lived link between data centers or peering arrangements among network service providers), setting up a PKI might be unnecessary. Instead, the public keys of all participating VPN devices can be directly installed on each device.

It is crucial to maintain the integrity and authenticity of these public keys. If an attacker installs incorrect keys, they could intercept information meant to be protected.

Certificates for Multiple Network Links

Complex networks will necessitate a PKI. It provides a means for each VPN endpoint to validate the identity of others, relying on a centralized set of services. The design, implementation, and management of a PKI are critical, as PKIs are appealing targets for attackers. If a PKI can be coerced into registering unauthorized devices or revealing private information (like signing keys), the network’s security may be compromised.

An x509-based PKI will require several physical and logical components, including a Certificate Authority (CA), a Registration Authority (RA), a root of trust, and a means for certificate revocation. The organization running this PKI needs to establish clear processes regarding these components.

Typically, a PKI that supports end entity cryptographic device identification is confined to a single relying organization. Therefore, it is essential for the organization to secure the processes and technology used by adhering to the following key points:

• Implement an ‘offline root’ model, where the PKI’s root remains disconnected from the network and powered down until necessary.

• Define processes for enrolling and revoking devices from the PKI. These should align with associated business activities to ensure that only expected endpoints possess valid certificates, and that all PKI-related activities are authorized and audited.

The lifetimes for the root and subordinate CAs should be set to the expected lifespan of the network or to specific dates (whichever comes first). We will review and update the following table as needed.

When multiple organizations will depend on certificates from a CA, a Certificate Policy (CP) and Certification Practice Statement (CPS) must be created and shared with all involved parties:

• The CP outlines the general policy governing the PKI.
• The CPS details the procedures that a CA follows to comply with the CP when issuing certificates, enabling others to evaluate whether such processes are credible; organizations should refer to RFC3647 when creating their CPS.

The PKI provider must establish the CP and CPS and define the permitted attributes for root, subordinate CA, and end entity certificates. We recommend that the following items be included in the CP/CPS:

• Appropriate certificate usage: end entity certificates are solely for creating encrypted links between endpoints within and across organizations.
• Certificate Revocation Lists (CRLs) must be accessible to all endpoints using certificates.
• Each CRL must comprehensively list all unexpired certificates issued by the CA that have been revoked.
• CRLs for end entity certificates should be published at least every 24 hours, with a suggested validity period of 192 hours. The root CA should publish a root CRL at least annually.
• Sub CA certificates must include one or more CRL Distribution Points (CDPs), specifying the root CA CRL URIs.
• Each issued certificate must have a non-null X.501 Distinguished Name in the certificate’s ‘subject’ name field, as mandated by RFC5280, uniquely identifying the device within the PKI.
• All values in certificates should be treated as public information, thus careful consideration should be given to naming conventions to avoid inadvertently including sensitive information.
• Anyone enrolling a device into the PKI must prove access to the private key that corresponds to the public key in the certificate, typically done by signing the request.
• Before issuing or reissuing a certificate, the RA or CA must validate the signature on the request and confirm that it is authorized.
• Certificates should be requested and used only on end entity devices that are part of the network.
• All certificate requests should be tied to a business process to ensure that only appropriate devices receive and renew certificates.
• Information regarding any cross-certification with other CAs must be made available to relying parties.
• If a certificate expires, is compromised, or is suspected to be compromised, then standard re-keying should be avoided.
• Changes to any information in the certificate should be authenticated in the same way as the initial registration.
• If a certificate is compromised or suspected of being compromised, it must be revoked immediately.
• A CA must enforce a separation of duties and, where necessary, adopt dual control for critical functions to prevent unauthorized actions within the CA system.
• User access should be limited to actions necessary for the performance of their defined responsibilities.
• There should be a designated individual accountable for the secure ongoing operation of the shared PKI service.
• PKI services should undergo rigorous penetration testing by qualified professionals, encompassing both internal and external threats as well as application-layer assessments.
• CA and RA private keys must be stored in secure facilities with appropriate access controls, allowing entry only to authorized personnel.
• CA and RA private keys should be generated using mechanisms or products certified by the NCSC.

4. Shared PKI Services

In certain scenarios, utilizing a shared PKI service across multiple organizations can be beneficial. Such a service may be managed by one organization on behalf of a broader community or supplied by a commercial provider for community VPN link support. In these cases, the PKI provider should implement the following points concerning central PKI infrastructure if it is to be shared among various organizations.

Providers offering PKI services to multiple clients may want to validate their processes against the principles outlined in their Certificate Policy and ensure they have been executed as stated in their Certificate Practice Statement through measures such as tScheme.

a. Data-in-transit Protection

Application-layer protection should be employed to maintain the integrity and authenticate requests and responses from the PKI service. Private keys should never be transmitted over these links, and certificates must always be authenticated through established points of trust or via out-of-band mechanisms. For further information, refer to Cloud Security Principles.

b. Asset Protection and Resilience

Users of the PKI service should be assured that their data, along with the assets holding or processing it, is protected against physical tampering, loss, damage, or seizure.

This entails:

• Organizations utilizing the PKI should be informed about the locations where their data will be stored, processed, and managed.
• The physical security of the locations providing the PKI service should be verified through CSA CCM v3.0, ISO/IEC 27001, or SSAE-16 / ISAE 3402 assessments.
• The PKI service provider’s protocols for physical security over media must be independently validated through CSA CCM v3.0, ISO/IEC 27001, or SSAE-16 / ISAE 3402.
• Components in the service provider’s architecture that perform security functions should reach Foundation Grade validation where possible.
• Assured products must be utilized to perform the sanitization of media containing user information before disposal.

c. Separation Between PKI Service Customers

Logical separation between different customers of the PKI should be designed and implemented to prevent a single malicious or compromised customer from impacting the service or data of another.

Access to the PKI service should be limited to organizations and individuals with a legitimate business requirement.

A qualified security architect (such as an individual with CCP-certified ‘IA Architect’ designation at Senior or Lead level) should oversee the architecture to ensure it is resistant to common attacks and incorporates adequate security controls, enabling effective and secure operation of the PKI service.

d. Governance Framework

The PKI service provider should have a governance framework that coordinates and directs its overall strategy for managing the PKI and the information it encompasses.

This includes:

• A clearly identified board representative (or an individual with direct delegated authority) responsible for the security of the PKI service, typically holding titles such as Chief Security Officer, Chief Information Officer, or Chief Technical Officer.
• A documented governance framework with policies that cover key aspects of information security concerning the PKI.
• Security considerations should be integrated into the service provider’s financial and operational risk reporting mechanisms.
• Processes must exist to identify and ensure compliance with applicable legal and regulatory requirements concerning the PKI.

e. Operational Security

The PKI service provider must have processes and protocols in place to ensure the operational security of the PKI, managing and operating it securely to thwart, detect, or prevent attacks.

This entails:

• Tracking the status, location, and configuration of service components (both hardware and software) throughout their lifecycle within the PKI.
• Assessing changes to the PKI for potential security impacts. Changes should be managed and documented until completion.
• Monitoring relevant information sources related to threats, vulnerabilities, and exploitation techniques.
• Keeping tabs on known vulnerabilities within the PKI until sufficient mitigations are implemented through a suitable change management process.
• Deploying ‘critical’ patches within 14 calendar days of their release; ‘important’ patches within 30 calendar days.
• Collecting events generated in PKI components vital for identifying suspicious activity, which are then analyzed.
• Having incident management processes in place for the PKI that respond to security incidents, validated using one of ISO/IEC 27035:2011, CSA CCM v3.0, or ISO/IEC 27001.

f. Supply Chain Security

PKI service providers often depend on third-party products and services, which can influence the overall security of the PKI service. The service provider should verify that any third parties it relies upon meet relevant security principles outlined in this document to an appropriate degree.

g. Identity and Authentication

Access to all PKI interfaces for consumers and service providers should be restricted to authenticated and authorized individuals. Weak authentication or access control can lead to unauthorized alterations to the PKI, resulting in data theft or modification, or denial of service. It is also essential that authentication occurs over secure channels. Using insecure channels, such as email, HTTP, or telephone, may increase vulnerability to interception or social engineering attacks.

h. Protection of External Interfaces

All external or less trusted interfaces of the PKI service must be identified and appropriately secured against potential attacks. If an exposed interface—potentially accessible to PKI consumers—lacks sufficient security, it could be exploited by attackers to access the PKI or its data. The impact may be more severe if the interface includes private components (such as management interfaces).

i. Audit and Monitoring

The PKI service provider must ensure that all activities which:

• Alter the set of certificates issued by the CA (e.g., addition, deletion, modification), or
• Impact the secure operation of the PKI

are audited in a manner that ensures traceability of actions, identification of individuals, and, where applicable, business processes. Access to the audit log should be limited to authorized personnel. Auditing mechanisms should also be designed to safeguard the integrity of audit information post-creation to prevent failure or compromise from affecting previous audit data.