Provisioning and managing certificates in the Web PKI

Provisioning and managing certificates in the Web PKI 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 helps architects, designers and engineers to make appropriate choices when obtaining and managing certificates to authenticate their online services to users. Note: This guidance focuses on server authentication rather than client authentication. Most use cases for client authentication are better served with a privately hosted Public Key Infrastructure (PKI), which the NCSC address in separate guidance. Introduction In the Web Public Key Infrastructure (Web PKI), certificates are used to demonstrate ownership of a domain or service to the end user. A third party, known as a Certificate Authority (CA): - verifies that the holder of a particular asymmetric key pair controls a given domain - creates a secure cryptographic association between the public key and the domain in a data structure called a certificate This certificate is then used for authenticating TLS connections that serve data to users. This authentication stems from two facts: - Only the holder of the private key associated to any given certificate can generate signatures that will correctly verify using the public key in that certificate. - End users trust the CA to verify that the legitimate domain-owner holds the private key. In a closed ecosystem, this can be achieved by creating and managing a private PKI which is described in the NCSC’s Design and build a privately hosted Public Key Infrastructure guidance. However, in an open ecosystem such as the internet, the private PKI approach would result in a bootstrapping problem; how does the user – who has had no prior contact with the domain or service – gain trust in the private root CA? To resolve this problem, the Web PKI was created. In the Web PKI, web browsers and operating systems maintain ‘trust stores’ of public root CAs, and any certificate which is cryptographically linked to one of these public root CAs will itself be trusted. Inclusion of a public root CA in a given trust store is subject to the CA operator demonstrating that it is meeting the standards agreed by the CA/Browser Forum, and any other rules the trust store may choose to impose. The CA/Browser Forum standards provide assurance that a CA is operating correctly and will only issue certificates to entities who can prove they control a domain or service. To summarise; users can trust a certificate as legitimate if the CA that issued it has a public root in the trust store. Threats to the Web PKI If you run a service dependent on the Web PKI, there are three principal threats you should be concerned about: - 1 An attacker obtains a certificate for your domain, with a private key that they control. This enables them to impersonate you, so they can exploit the trust users have in your brand to deliver misinformation or malware. The primary mitigations to this threat are around reducing the likelihood and impact of compromise. - 2 Certificate mis-management results in you having a weakened certificate, or no certificate. This means that users have no way of securely connecting to your service, at best meaning their browser will prevent them from connecting, and at worst meaning that they will connect insecurely and an attacker will be able to break the confidentiality of this connection. The primary mitigations to this threat are around reducing the likelihood of weak or expired certificates. - 3 You’re unaware that either of the above threats have been realised, meaning that you’re slower to react so the damage is prolonged and affects more users. The primary mitigation to this threat is to monitor certificate issuance and renewal. The recommendations in this guidance are targeted at mitigating one or more of these threats and are grouped as such. Reduce the likelihood and impact of compromise The security provided by a certificate largely stems from the secrecy of the private key, so it is absolutely imperative that you protect the confidentiality of your private keys. If an attacker can obtain the private key for your domain, then they can serve malicious content which appears to come from that domain. It is also important to protect the integrity and availability of your private key. If an attacker can modify or deny access to a private key, then you will not be able to generate valid signatures. This means users can no longer trust your content, and will be unable to connect securely, disrupting service availability and potentially causing reputational damage. We do not recommend keeping backups of private keys used in the Web PKI, as this introduces a new confidentiality risk (as each backup key also needs to be securely managed, which often outweighs the availability risk you’re trying to mitigate). If a private key is lost or corrupted, obtaining a new certificate is generally safer and easier than keeping a backup and restoring the key. If hosting your service in the cloud then we recommend using the native cloud key management service (KMS) to generate and protect your private keys. The KMS should be trusted to perform these roles, and options such as exporting keys for backup or ‘bring your own key’ (BYOK) / ‘hold your own key’ (HYOK) should be avoided. As a general rule when configuring the KMS, you should choose options that reduce human access to private keys. Certificate revocation is the process by which certificates can be invalidated before they naturally expire. There are several events that would warrant revocation, ranging from known or suspected private key compromise through to simply not running the domain or service any longer (and thus not needing the certificate). In order to revoke a certificate, the issuing CA adds the certificate to a publicly available list known as a Certificate Revocation List (CRL). Then, when validating a certificate, the client verifies that the certificate they are attempting to authenticate is not contained in the CRL of the issuing CA, implying that it remains valid. In the Web PKI, CRLs grow too large to be practical for clients to use directly, and so most browsers have innovated bespoke solutions to use in certificate chain validation. Common examples include CRLSets, which selects a subset of the CRLs to use (generally only high profile and/or CA certificates), and CRLite, which embeds the revocation information contained in the CRLs into a more compact data structure, but such solutions are not ubiquitous across all clients. A mechanism called Online Certificate Status Protocol (OCSP) was designed to avoid end users having to obtain and store massive CRLs. In this case, the OCSP responder is responsible for obtaining the up-to-date CRL from the CA and checks the certificate status on behalf of the end user. This service is costly to run since it needs to be highly available, resilient and scalable to ensure that OCSP provides any security benefit, and is not mandatory for CAs to implement. Additionally, there are privacy concerns with OCSP as in order to obtain revocation information, the client has to divulge the domain or service it wishes to access to the OCSP responder. An alternative is OCSP stapling, in which the domain or service obtains the OCSP response for its certificate and provides it to clients itself and so protects the client privacy. However, OCSP stapling is not particularly well supported in the Web PKI. In summary, neither CRLs nor OCSPs as they’re currently deployed provide an ideal solution to the revocation problem for the Web PKI. Despite this, in response to a revocation-worthy event, we still strongly recommend that a domain or service owner revokes this key through the CA (possibly via your certificate management automation software) and gets it added to the CRL. However, this should be done in the knowledge that it cannot be guaranteed that this revocation status will percolate through to all end users. As a general principle, any given infrastructure device should only have access to the private keys necessary for its role. Furthermore, any certificates associated to these private keys should be scoped to cover only the domains being served by that device. This prevents unnecessary private key proliferation and helps to reduce the chance and impact of any compromise. If you are serving multiple domains from the same infrastructure hardware, you don’t need to arbitrarily segregate these under different certificates, as compromising a single device compromises all private keys stored on it. A single certificate, with the specific domains listed in the certificate’s Subject Alternative Names (SAN) extension, will likely be sufficient and gives you fewer certificates to manage which can be beneficial. This said, if you have a large number of SANs in your certificate then this can increase loading times for users connecting to your service. If you’re using certificate management automation software then, depending on your tooling, the additional key and certificate management overhead from having a certificate per domain may be minimal, and so this approach could be suitable. Another consideration is whether or not to use IP Address Certificates (certificates issued to an IP address rather than a domain name). Within the web, IP addresses are typically much more ephemeral and changeable than domain names. Since the majority of users will be connecting to your services via domain names – and relying on DNS to find the associated IP address – for most use cases domain name certificates provide greater assurance of identity and so should be preferred. IP Address Certificates are necessary for some niche cases, such as authenticating connections to secure DNS servers, or securing connections where you don’t have a domain name (for example to IoT devices). A wildcard certificate has a wildcard character (*) in the domain name field, which means it is valid for any subdomains fitting the pattern (so *.example.com would be valid for http://www.example.com , mail.example.com and whateveryouwant.example.com). If you’re serving these domains from distinct infrastructure hardware, then using a single wildcard certificate to cover them all is not recommended. A compromised wildcard certificate could be used by an attacker-created subdomain to appear legitimate (as *.example.com would also be valid for an attacker created nefarious.example.com). We recommend that the use of wildcard certificates should be limited to the cases where wildcard certificates are genuinely necessary, for example where subdomains are dynamic as they can be for per-customer subdomains). Where possible, specifying individual domains should be preferred. By default, any CA is permitted to issue a certificate for any domain. Using a Certificate Authority Authorisation (CAA) DNS record, as defined in RFC 8659, you can restrict this so that only your chosen CA is permitted to issue certificates for your domain. This works because CAs are required by the CA/Browser Forum Requirements to inspect the CAA record to ensure that they are a permitted CA for a domain before issuing a certificate to that domain. It is worth noting that when searching for CAA records, the CA will always respect the CAA closest to the domain name you’re requesting a certificate for (so any CAA record for a subdomain will override the CAA on the domain). CAA records are of particular use in prohibiting the issuance of wildcard certificates. By setting a CAA record that has an “issuewild” Property Tag which does not identify an authorised CA (that is, with Value “;” ) you are stating that no CA has the authority to issue wildcard certificates in the jurisdiction of the CAA record. If wildcards are necessary on a particular subdomain, then you can override a domain wide wildcard ban with an issuewild CAA record on that subdomain identifying your chosen CA. The NCSC recommend creating a CAA record for all of your domains, and further recommend that the CAA record be as specific as possible (by using, for example, the “validationsmethods” and “accounturi” Parameters as defined in RFC 8657 where supported). CAs that help you to set a correct CAA record should be preferred. Reduce the likelihood of weak or expired certificates Certificates are issued with a fixed time period during which they are valid. When your current certificate is about to expire, you must contact the CA to obtain a new certificate which will be valid further into the future. The use of automated certificate management protocols (such as ACME) reduces the manual burden of managing certificates and prevents human error from allowing certificates to expire, leaving you without a valid certificate. If you don’t have a valid certificate then clients cannot securely connect to your service, disrupting availability and potentially causing reputational damage. When managing your certificates with an automated protocol, an important decision is the renewal timeframe (that is, the time before the current certificate expires that you renew). You should select a timeframe that is sufficient to both detect and fix any renewal issues before the old certificate expires. CAs and/or certificate management automation software usually have recommended default timeframes to renew when there is between ¼ and ⅓ of the certificate validity period remaining, which will be appropriate in most cases. Certificate management automation software has the authority to act on your behalf and request certificates for your domain. It is therefore important to appropriately secure this software (and the credentials for any accounts used to interact with it) to ensure that the software cannot be subverted. If using ACME, and your CA supports it, you should consider using the ACME Renewal Information (ARI) extension as defined in RFC 9773, which provides an automated way for the CA to request that you renew early (and can therefore prevent you being left ‘certificateless’ in the case that the CA needs to revoke your certificate early). Additionally, the extension can help CAs manage load spikes and so prevent your renewal from being delayed. When renewing a certificate it is good practice to generate a new private key for the new certificate, rather than re-using the current one. By changing the private key, you mitigate the risk posed by undetected compromise of your private key (since the old private key will be of no use to an attacker when the old certificate expires). The validity period for your certificates is a decision that needs to balance the impact of a certificate being compromised with the threat to service availability from failed renewal. For example, a long validity period will result in a greater time period that a compromised certificate can be misused before it naturally expires, but provides a greater time period in which to fix any issues that arise in renewal. In general, CAs will offer a default validity period which should be appropriate for most use cases. Some CAs also offer ‘short-lived subscriber certificates’, defined by the CA/Browser forum as certificates with a validity period less than or equal to 10 days (reducing to 7 days in 2026) and exempt from some of the CA/Browser requirements around revocation due to their short validity period. The general trend in the ecosystem is towards shorter validity periods for certificates and the CA/Browser Forum has passed a ballot to reduce the maximum certificate validity periods permitted in the Web PKI in a series of steps, culminating in 2029 with 47 days. You should prepare for this and understand the impact of any changes that your CA will be implementing to comply with the CA/Browser Forum’s timelines. As recommended above, using certificate management automation software will reduce the manual effort required for the frequent renewal of certificates with shorter validity periods. Given the shortening of certificate validity periods, it is imperative to have effective monitoring on the certificate management automation software to enable any issues to be identified, diagnosed and resolved before the current certificate expires. Using outmoded algorithms can leave you vulnerable to cryptographic attacks. For the Web PKI, the CA/Browser Forum specifies supported algorithms, introducing new algorithms (when the standards are sufficiently mature) and retiring old algorithms when they are superseded. However, it is not necessarily true that all permitted algorithms will be appropriate for your given use case. Suggested algorithms and parameter sets can be found in the NCSC guidance on Using TLS to protect data. The classical cryptographic algorithms currently used within the Web PKI are vulnerable to the threat posed by cryptographically relevant quantum computers, and so in the coming years there will be a necessary transition to post-quantum cryptography. For more information please refer to the NCSC’s guidance on Timelines for migration to post-quantum cryptography. When issuing a certificate to an entity, the CA is responsible for verifying that the entity requesting the certificate has control over the domain they’re requesting a certificate for. Fundamentally this is to ensure that a malicious actor cannot pretend to own a domain they don’t. The CA/Browser Forum defines several methods for performing domain validation (such as DNS Change, TLS Using ALPN and Agreed-Upon Change to Website - ACME) and we suggest selecting the most practical method supported by your chosen CA and certificate management automation software. The resultant certificate is known as a Domain Validation (DV) certificate. Some CAs also offer Organization Validation (OV) and/or Extended Validation (EV) certificates which require additional checks on the organisation making the request (such as confirming physical address, phone number and company records). Whilst these additional assertions are encoded within the certificate, web browsers now treat DV, OV and EV certificates as equivalent and so there are no functional or security benefits to OV or EV certificates. In addition, the supplementary validation checks required when issuing OV/EV certificates usually require manual human intervention and so cannot be fully automated. Therefore, the NCSC recommends that DV certificates should be preferred in all use cases. Monitor certificate issuance and renewal You should monitor your certificate renewal to ensure that any certificates you have in use don’t expire unexpectedly without having been renewed, for example due to misconfiguration, hardware failure or software failure. This is equally important for both manual renewal and when employing certificate management automation software, as in both cases early warning gives you more time to diagnose and fix any issues. In order to do this effectively, you will need to maintain awareness of which certificates are in use where, and we suggest this forms part of your general domain name management. Additionally, monitoring the access control on your private keys ensures that you have a full picture (meaning people and hardware) of who can access which keys, and who is attempting to use them. This can provide an early indication of malicious activity. As part of certificate issuance, CAs can publish records to Certificate Transparency (CT) logs. These are publicly available, append only ledgers of all certificates which have been issued and – although not mandated by the CA/Browser Forum – proves that a certificate has been added to CT logs (known as Signed Certificate Timestamps) are required by most major Web Browsers. So, CAs that publish to CT logs should be preferred. Through monitoring CT logs, it is possible to track the certificates that have been issued for a given domain, and thus to gain early warning of any certificates which have been unexpectedly issued for your domains. Such issuance could indicate a compromise of the domain (since proof of domain control is required to obtain a certificate) which can be further investigated. Several public and commercial services exist for the monitoring of CT logs, often as part of a wider certificate management package. We recommend that monitoring of CT logs for unexpected activity relating to your domains forms part of your monitoring strategy. Summary Certificates and the Web PKI are critical technologies for enabling users of your domains and services to ensure that what they’re interacting with is legitimate. Failure to properly manage certificates for your domain will at best lead to reputational damage, with users unable to connect securely to your domain or service, and at worst can permit an attacker to capture customer data or to impersonate your service. The recommendations in this guidance aim to mitigate these threats by reducing their likelihood and impact as much as possible, and ensuring that you are aware of any issues as soon as possible.