Certificate outages and mis-issuance rarely start with a cryptographic failure; they start with a certificate nobody knew about, owned by nobody, renewed by a process nobody monitored. This template gives [Organisation] a register for every X.509 certificate it depends on: public and private TLS certificates, mTLS client certificates, device certificates, and the code-signing and S/MIME certificates that have their own handling. Each record captures the owner, the issuer, the validity dates, the renewal method, where the private key lives and every endpoint that serves or trusts the certificate. It is built for the shorter lifetimes now in the CA/Browser Forum Baseline Requirements, where publicly trusted TLS certificates issued from 15 March 2027 may be valid for at most 100 days, and from 15 March 2029 at most 47 days. It is written for PKI, platform and site reliability teams and for auditors. Per-certificate renewal steps belong in the Certificate Renewal Runbook Template; the register is the list those runbooks hang from.
How to use this template
- One row per certificate, grouped by family: each issued certificate (identified by issuer and serial) is a row. Add a Family ID so that renewals of the same name, owner and deployment path link together; when a certificate is renewed, close the old row and open a new one with the same Family ID.
- Required and Recommended: Required fields are the minimum to prevent expiry outages and support incident response. Recommended fields support crypto-agility, post-quantum planning and audit.
- Populate from tools, not people: fill the technical fields (serial, dates, issuer, key algorithm) from discovery scans, CA exports and certificate lifecycle management (CLM) tools. People supply owner, purpose and dependency fields.
- Never store private keys or passphrases: record the key location and who can access it. The register is still sensitive, because it maps where keys live: restrict access to [PKI team], [Security team] and auditors.
- Use fixed values: drop-downs for certificate type, CA type, renewal method, key location and status, so you can count and filter.
- Replace bracketed text: [Organisation], [CLM tool], [Monitoring system] and the bracketed thresholds take your own values. Thresholds shown are NHI Mgmt Group suggestions.
1. Purpose
1.1 This register records every certificate that [Organisation] systems present or rely on, so that each certificate has an accountable owner, a known renewal path, a protected key, a complete list of deployment points and an expiry date that is monitored.
1.2 It is the authoritative source for expiry alerting, renewal planning, CA migration and mass replacement events, and evidences NIST SP 800-53 Rev. 5 SC-17 Public Key Infrastructure Certificates, SC-12 Cryptographic Key Establishment and Management and CM-8 System Component Inventory, and NIST CSF 2.0 ID.AM-02. The Certificate Management Policy Template makes keeping it current mandatory.
2. Scope and certificate types
| Certificate type | Examples | Primary discovery source | Register notes |
|---|---|---|---|
| Public TLS server | Websites, APIs, mail servers using publicly trusted CAs | Certificate Transparency logs for your domains, external scans, CA account exports | Subject to Baseline Requirements lifetimes; DCV and CAA fields required |
| Private TLS server | Internal services, admin consoles, databases | Internal network scans, internal CA database, CLM tool | Validity set by your CA policy, not the Baseline Requirements |
| mTLS client and workload | Service-to-service identities, service mesh, partner API clients | Mesh control plane, internal CA, API gateway configuration | Often short-lived and automated: register the issuing policy, not each certificate |
| Device and user authentication | 802.1X, VPN, MDM-enrolled device certificates, smart cards | MDM, SCEP or EST server logs, AD CS | Register by template and population count |
| Cloud-managed | Certificates issued and renewed by a cloud certificate service and attached to load balancers or CDNs | Cloud provider certificate service APIs | Record renewal eligibility conditions from the provider's docs |
| Code signing and S/MIME | Release signing, document and email signing | CA accounts, HSM inventory | In scope for inventory; response handled by the Compromised Code Signing Certificate Playbook |
| CA certificates | Your root and issuing CAs, and third-party roots in your trust stores | CA configuration, trust store exports | Separate tab; feeds trust store management |
2.1 High-volume short-lived certificates (for example workload certificates rotated hourly) are registered at the level of the issuing policy or template, with the population count and maximum lifetime, rather than one row each. SSH certificates follow the same rule; see the SSH Protocol and Certificate Authority Guide.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Register owner [PKI lead] | Runs discovery and reconciliation, reports metrics, manages the register tool |
| Certificate owner | Accountable for one family: renewal, deployment, accuracy of dependency fields |
| Service owner | Confirms which services depend on the certificate and their criticality |
| CA or CLM administrator | Maintains CA and ACME accounts, issuance policies and exports |
| DNS administrator | Maintains CAA records and DNS validation records |
4. Identification and issuer fields
| Field | Guidance | Status |
|---|---|---|
| Record ID and Family ID | [CERT-00001]; Family ID links successive renewals | Required |
| Certificate type | Drop-down from Section 2 | Required |
| Subject and SANs | Common name and every subjectAltName entry; flag wildcards | Required |
| Serial number | Hex, as issued | Required |
| SHA-256 fingerprint | Used to match scan results to records | Required |
| Issuer and issuing CA | Issuer distinguished name and the CA product or service | Required |
| CA type | Public, private internal, cloud-managed private, self-signed | Required |
| Authority Key Identifier | Needed with the serial to build the ACME Renewal Information certificate identifier (RFC 9773) | Recommended |
| Chain | Intermediate and root, so a CA distrust or intermediate change can be traced | Recommended |
| Signature algorithm | For example sha256WithRSAEncryption, ecdsa-with-SHA256 | Recommended |
5. Validity and renewal fields
| Field | Guidance | Status |
|---|---|---|
| notBefore and notAfter | From the certificate, in UTC | Required |
| Validity period (days) | Calculated; check against the Baseline Requirements limit for the issue date (public TLS) or your CA policy | Required |
| Renewal method | ACME client (name and version), cloud managed renewal, CLM automation, manual CSR | Required |
| Renewal trigger | Fraction of lifetime remaining, CA's ARI suggested window, or fixed date; fixed day counts fail as lifetimes shorten | Required |
| ARI supported | Whether the CA publishes renewalInfo and the client uses the suggestedWindow | Recommended |
| Domain validation method | HTTP-01, DNS-01, TLS-ALPN-01, or other method allowed by the CA (public TLS only) | Required for public TLS |
| Validation reuse expiry | When the CA's stored domain validation lapses; the Baseline Requirements cut domain name validation reuse to 100 days from 15 March 2027 and 10 days from 15 March 2029 | Recommended |
| CAA record | Whether the domain publishes CAA (RFC 8659) issue and issuewild tags naming the CA, and any accounturi or validationmethods parameters (RFC 8657), which the Baseline Requirements oblige CAs to process from 15 March 2027 | Required for public TLS |
| Last renewal result | Date, success or failure, error | Required |
| Renewal runbook | Link to the runbook for this family | Required for Tier 1 |
5.1 Do not rely on CA emails for expiry warnings. Let's Encrypt stopped sending expiration notification emails on 4 June 2025, and other CAs send notices to whichever address was on the order. Expiry alerts must come from your own monitoring of the register and of served certificates.
6. Key fields
| Field | Guidance | Status |
|---|---|---|
| Key algorithm and size | RSA 2048 or 3072, ECDSA P-256 or P-384, Ed25519, ML-DSA where used | Required |
| Key location | HSM, cloud KMS, secrets manager, file on host, keystore (JKS or PKCS#12), appliance | Required |
| Key path or reference | Key ID, vault path or file path; never the key | Required |
| Exportable | Yes or No | Recommended |
| Key reused on renewal | Yes or No; new keys on each renewal limit exposure | Recommended |
| Who can access the key | Accounts, roles and service identities with read access | Required for Tier 1 |
| Issuing credential | ACME account key, CA portal account or API token used to obtain the certificate, and its storage location; these are non-human identities | Required |
6.1 The ACME account key and CA API tokens can issue certificates for your names. Register them in the NHI inventory with an owner and rotation date, as described in the Machine Identity, PKI and Certificate Lifecycle Guide. If a key is exposed, follow the Leaked TLS Private Key Response.
7. Deployment and dependency fields
| Field | Guidance | Status |
|---|---|---|
| Deployment targets | Every host, load balancer, CDN, ingress, API gateway, keystore and appliance that serves the certificate | Required |
| Served serial check | Date and result of the last external or synthetic check that the endpoint presents this serial | Required |
| Dependent services and tier | Service names and business impact tier | Required |
| Relying parties | Clients, partners or devices that trust it, including any that pin the certificate or its key | Recommended |
| Reload method | Automatic, service restart, manual import, appliance upload | Recommended |
| Environment | Production, staging, development | Required |
8. Ownership and status fields
| Field | Guidance | Status |
|---|---|---|
| Certificate owner and deputy | Named people; alerts go to a team route as well | Required |
| Alert route | Paging or ticket queue, never one person's mailbox | Required |
| Status | Active, Renewal due, Superseded, Revoked, Expired (unused), Expired (in use: incident) | Required |
| Revocation reason and date | Where revoked | Required when revoked |
| Last review | Date and reviewer | Required |
9. Alert thresholds and review
9.1 Express thresholds as a share of the validity period, so they keep working as lifetimes shorten. The values below are NHI Mgmt Group suggestions.
| Condition | Alert | Severity |
|---|---|---|
| Automated renewal has not succeeded when [one third] of the lifetime remains | Ticket to certificate owner | Warning |
| [One sixth] of the lifetime remains, or [7] days, whichever is sooner, with no successor | Page on-call | High |
| Served serial differs from the active register record | Ticket to owner | High |
| Certificate in CT logs for your domains with no register record | Ticket to PKI team | High |
| Expired certificate still served | Open incident path in the renewal runbook | Critical for Tier 1 |
9.2 Owners confirm their records every [6] months; Tier 1 families every [3] months and after any CA, key location or deployment target change.
10. Discovery and reconciliation
- Certificate Transparency: monitor CT logs for every registered domain, so public certificates issued outside the process appear. See the Certificate Transparency Monitoring Guide for Web Teams.
- Network scans: scan internal and external address space on TLS ports (443, 8443, 636, 993, 995, 465 and service-specific ports) and match fingerprints to records.
- CA and cloud exports: pull issued-certificate lists from each CA account, internal CA and cloud certificate service.
- Hosts and keystores: agent or script inventory of certificate stores, keystores and PEM files.
- Identity platforms: application credentials such as certificates on app registrations; see How to find expiring app secrets and certificates in Entra ID.
10.1 Each run records new unregistered certificates, records with no evidence of use for [60] days, and mismatches between served and registered serials. Unregistered certificates get an owner within [5] working days or are scheduled for revocation.
Implementation guidance
- Start with what can take you offline: public certificates on customer-facing services and private certificates behind Tier 1 services first. CT logs and a CA export give a public list in a day.
- Check renewal triggers before March 2027: any family renewed on a fixed day count, or with a manual step, needs a new trigger or automation before the 100-day limit applies. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide and the ACME and Automated Certificate Management Guide.
- Expect these first-run findings: certificates owned by people who have left, wildcards deployed far beyond their intended scope, keys copied to many hosts, appliances with manual import, and expired certificates still served on internal endpoints.
- Feed crypto-agility work: key algorithm, signature algorithm and chain fields let the register double as the certificate part of a cryptographic inventory. See the Cryptographic Inventory and CBOM Guide.
- Metrics to report monthly: certificates by type and tier; percentage with a named owner; percentage renewed automatically; certificates within the alert window with no successor; unregistered certificates found and median time to resolve; expiry incidents.
- Framework alignment: NIST SP 800-53 Rev. 5 SC-17, SC-12 and CM-8; NIST CSF 2.0 ID.AM-02. NIST SP 1800-16 covers large-scale TLS server certificate management in depth.
- Key sources: CA/Browser Forum: Baseline Requirements for TLS Server Certificates; CA/Browser Forum: Ballot SC-081v3; NIST SP 1800-16: TLS Server Certificate Management; IETF RFC 9773: ACME Renewal Information; IETF RFC 8659: CAA Resource Record; Let's Encrypt: Ending expiration notification emails.
Related NHI Mgmt Group resources: Certificate Renewal Runbook Template · PKI and Certificate Lifecycle Maturity Model · CA Compromise and Mass Certificate Replacement Playbook · Privileged Account Inventory Template