Provisioning and securing security certificates

In most cases involving IPsec and TLS VPN connections, devices and gateways must utilize certificates that are validated by a centralized trust framework in order to identify themselves appropriately. Each authorized endpoint should have a distinct end entity X.509v3 certificate that is registered with the trust infrastructure. This process must prevent the registration of unauthorized certificates, thereby ensuring the reliability of the centralized trust architecture.

The trust infrastructure, commonly termed Public Key Infrastructure (PKI), is typically managed by the organization that provides the encryption service. Local PKIs may establish trust relationships with other PKIs to facilitate encrypted communications among devices owned by different organizations.

Since PKIs are attractive to adversaries due to the sensitive data they manage (especially private keys) and their role in ensuring trust, a breach in their security can lead to dire and difficult-to-detect repercussions. Therefore, it is essential to robustly protect PKIs from potential threats. To this end:

• We strongly advise against sharing PKIs among communities with vastly differing security requirements or operational contexts, such as commercial entities and public sector organizations.
• When designing a PKI for varied service types (IPsec, TLS, S/MIME, etc.), it is recommended to utilize distinct subordinate CAs for each function to mitigate the risk of a compromised certificate being misused across services. Consideration of alternative strategies such as the utilization of separate Certificate Policy OID (CPOID) values, alongside specific key usage and extended key usage fields, may also be prudent.
• We discourage the use of Pre-Shared Keys (PSKs), Group Domain of Interpretation (GDOI), and comparable methods for generating shared keys among end devices.
• All devices must validate the certificates they rely upon, ensuring they have mechanisms such as Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) to verify certificate statuses within the PKI.
• It is critical for devices to verify the validity of the complete certificate chain, including the end entity certificate, any subordinate CA certificates, and the root certificate. A three-layer depth is recommended for PKI hierarchies.

End entity certificates should conform to the X.509v3 standard and include necessary cryptographic features for the chosen IPsec or TLS profiles.

• Certificates must be created by an administrator on the device intended for their use, unless the device’s security policy suggests a different generation protocol.
• Private keys associated with certificates should remain solely within the device they are operational on.
• End entity certificates should maintain a validity period of one year or align with the expected lifecycle of the device, whichever is shorter.

Certificates for Limited Connections

In scenarios where only a few VPN endpoints are necessary (e.g., a long-lasting data center-to-data center connection or peer networking arrangements), the establishment of a PKI may be considered excessive and unnecessary. In such cases, individual public keys can be directly installed on each participating device.

It is critical to ensure the integrity and authenticity of these public keys. Incorrect keys can lead to unauthorized information access.

Certificates for Multiple Links

Complex networks necessitate the use of a PKI. The PKI facilitates the validation of identities among VPN endpoints, relying on a centralized resource for service delivery. Given that PKIs can be attractive targets for attackers, their design, implementation, and management are key factors in sustaining network security. Failure to secure a PKI can result in unauthorized device registration or the exposure of sensitive private information.

An X.509-based PKI comprises several physical and logical components, which include a Certificate Authority (CA), a Registration Authority (RA), a root of trust, and mechanisms for certificate revocation. The organization managing the PKI must establish protocols governing these components.

Typically, a PKI should function within a single organization. To achieve this, the organization must ensure appropriate security for the technology and processes employed by adhering to several principles:

• Implement an ‘offline root’ model, where the root component remains disconnected from any network and powered down until called upon.
• Create detailed enrollment and revocation protocols for devices to regulate which endpoints obtain valid certificates.

The lifespan of the root and subordinate CAs must reflect the expected operational period of the network, or match the specified dates listed below (whichever is earlier). A review of the following schedule will be conducted periodically:

If multiple organizations will be relying on the certificates provided by a Certification Authority, a Certificate Policy (CP) and Certification Practice Statement (CPS) need to be compiled and shared with all involved parties:

• The CP outlines the overarching policies of the PKI.
• The CPS details the procedures and practices that a CA must follow to meet the CP’s requirements when issuing certificates, allowing other entities to determine if they can trust these processes; RFC3647 may serve as a guide for the CPS development.

It is incumbent upon the PKI provider to articulate the CP and CPS, as well as define the permissible attributes associated with root, subordinate CAs, and end entity certificates. The following stipulations are recommended for inclusion in a CP/CPS:

• Designated certificate usage: end entity certificates are solely for enabling encrypted links between endpoints across organizations.
• Accessible Certificate Revocation Lists (CRLs) for all endpoints employing certificates.
• CRLs must comprehensively document all unexpired certificates revoked by the CA.
• Updates to end entity CRLs should occur at least every 24 hours, ideally retaining a validity of 192 hours (8 days), while root CAs should publish their own CRLs at least annually.
• Sub CA certificates should incorporate one or more CDPs indicating the root CA’s CRL URIs.
• Each certificate issued needs a non-null X.501 Distinguished Name within the ‘subject’ field, per RFC5280. This must uniquely identify the device within the PKI context.
• Elements used within certificates must be treated as public information; thus, careful consideration should be given to naming conventions to avoid inadvertent inclusion of sensitive information.
• Those enrolling devices in the PKI must demonstrate their access to the corresponding private key, typically through signature verification of their request.
• Each certificate request is verified for validity and authorization by the RA or CA before issuing or reissuing.
• Certificates are only to be requested and utilized on designated end entity devices as part of the network.
• All certificate requests must align with established business processes to ensure only legitimate devices are granted or renewed certificates.
• Cross-certification details with other Certificate Authorities must be accessible to relevant parties.
• If a certificate is expired, compromised, or suspected to be compromised, routine re-keying will not be performed.
• Alterations to certificate information must be authenticated in alignment with the registration process.
• A compromised certificate must be promptly revoked.
• It is vital to ensure clear separation of duties and, if necessary, dual control for essential CA operations to thwart malicious activities undetected.
• Access for users must be limited to necessary functions according to defined responsibilities.
• A designated individual must oversee the secure, ongoing operation of the shared PKI service.
• PKI services should undergo thorough penetration testing by qualified personnel, covering both internal and external threat vectors alongside application security testing.
• PKI private keys must reside in secure locations, enforced through strict access protocols limiting entry to authorized individuals only.
• Mechanisms or products sanctioned by the NCSC should be employed for the generation of CA and RA private keys for PKIs.

4. Shared PKI Services

In instances where having multiple organizations access a shared PKI service is advantageous, this service could either be managed by one organization for a broader community or offered by a commercial vendor to support a set of VPN links. Should this apply, the following measures should be established by the PKI provider to facilitate a shared PKI infrastructure.

Providers supporting multiple clients may need to independently validate their processes align with the principles in their CP and have been executed according to their CPS, employing methods such as tScheme.

a. Protecting Data in Transit

Application-layer security ought to be utilized to safeguard the integrity of requests and responses from the PKI service. Transmitting private keys over these connections is inadvisable, and certificates must be validated – either through known trust sources or via out-of-band protocols. Further details can be found in the Cloud Security Principles.

b. Assets and Resilience

Utilizers of the PKI service must be assured that their data, as well as the systems that store or process it, remain secure against physical tampering, loss, damage, or seizure.

This necessitates that:

• Information on data storage and processing locations must be available to organizations using the PKI.
• The physical security of facilities hosting the PKI service should be validated independently through CSA CCM v3.0, ISO/IEC 27001, or SSAE-16 / ISAE 3402.
• Procedures for physically securing media must be independently validated through the same standards.
• Components executing security functions within the service framework should meet Foundation Grade validation standards, when applicable.
• Sanitization processes for media containing user data, prior to disposal, should employ approved products.

c. Separation for PKI Customers

It is essential to implement logical separation to prevent a single malicious actor from compromising the PKI service or adversely affecting the data of another customer.

Access to the PKI service needs to be restricted to organizations and individuals who have a legitimate business rationale for its use.

Involving a qualified security architect, such as someone certified at the Senior or Lead level with CCP’s ‘IA Architect,’ will help design an architecture that mitigates common threats, implements appropriate security controls, and supports secure PKI operations.

d. Governance Framework

The PKI service provider needs to maintain a governance framework that unifies and guides its management practices concerning the PKI and its information.

This includes:

• Identification of a board member or executive with the direct authority responsible for PKI security, often titled Chief Security Officer, Chief Information Officer, or Chief Technical Officer.
• Documenting a comprehensive governance framework, which includes policies influencing key aspects of PKI-related information security.
• Integrating security and information security processes into financial and operational risk assessments.
• Maintaining procedures for recognizing and adhering to legal and regulatory standards pertinent to the PKI.

e. Operational Security

Operational security processes must be established by the PKI provider to guarantee the secure management of the PKI. This is critical for detecting, impeding, or thwarting potential attacks.

<pessential practices="" include:

• Tracking the status, location, and configurations of service components (both hardware and software) throughout their lifecycle.
• Assessing the security impact of any changes to the PKI, and ensuring changes are managed and recorded until complete.
• Monitoring relevant sources for information regarding potential threats, vulnerabilities, and exploitation techniques.
• Documenting known vulnerabilities within the PKI until suitable mitigations are implemented through an established change management system.
• Applying ‘critical’ patches within 14 days of issuance, and ‘important’ patches within 30 days.
• Collecting events from PKI components necessary to identify suspicious activity and feed this into an analysis system.
• Implementing incident management protocols for the PKI and ensuring they are enacted in response to security events, validated through one of ISO/IEC 27035:2011, CSA CCM v3.0, or ISO/IEC 27001.

f. Supply Chain Security

Third-party products and services are often integral to PKI service providers. Considering the potential impact on overall security, providers must ensure that any third parties they rely on can meet the applicable security requirements enumerated in this document.

g. Identity and Authentication

Access to all PKI interfaces by consumers and service providers must be constrained to authenticated and authorized individuals. Weak access controls can lead to unauthorized alterations in the PKI, including data theft, modification, or service denial. Secure channels are imperative for authentication to prevent interception or social engineering exploits.

h. Protection of External Interfaces

All less secure or external interfaces associated with the PKI service must be identified and fortified against potential attacks. Inadequate protection of exposed interfaces could enable attackers to compromise the PKI system or access confidential data.

i. Auditing and Monitoring

The PKI service provider must ensure that any activities which:

• Alter the certificate set issued by the CA (e.g., addition, deletion, update), or
• Impact the secure functioning of the PKI

are subject to auditing that guarantees action traceability, individual identification, and, when appropriate, procedural adherence.

Access to audit logs should be restricted to authorized personnel only. The auditing mechanisms should be designed to uphold the integrity of the secured audit information so that past entries remain protected from subsequent failures or breaches.