NIST’s National Cybersecurity Center of Excellence says enterprises should establish a formal TLS server certificate management program with executive responsibility, clear policy, accountable certificate owners, and a central certificate service. The final NIST SP 1800-16 executive summary connects poor certificate management to outages, security incidents, and difficulty replacing certificates or keys rapidly after a cryptographic weakness or certificate-authority compromise.
\r\nThe guide’s scope is TLS server certificate management. It does not replace secure TLS protocol configuration guidance, manage every client certificate, or endorse the commercial products used in NIST’s example implementation. DSE therefore treats it as a vendor-neutral operating model, not a product shopping list or proof of compliance.
\r\nVolume B organizes recommended practices around inventory, ownership, approved certificate authorities, validity periods, key and signing requirements, subject and alternative names, request review, private-key security, proactive renewal, revocation, crypto-agility, continuous monitoring, logging, and trust. It recommends a central certificate service that supports discovery, inventory, enrollment, installation, renewal, reporting, monitoring, and integration with enterprise identity, ticketing, configuration-management, and audit systems.
\r\nNIST’s laboratory implementation demonstrates automated discovery and management across technologies, including proxies, load balancers, and inspection appliances. That example shows feasibility; it does not mean automation can safely replace application testing or accountable approval.
\r\nStart with discovery, then reconcile the results to applications rather than accepting a scanner list as the inventory. For each certificate, record the service and environment, network names, owner and backup owner, business criticality, issuer, approval path, deployment locations, key location and protection method, renewal mechanism, dependencies, and retirement condition. Include internal services and nontraditional endpoints. Cloud gateways, application delivery controllers, security appliances, container ingress, developer-managed endpoints, and dormant disaster-recovery systems are common blind spots.
\r\nMake ownership actionable. The application owner should validate names, deployment, maintenance windows, and service behavior. A certificate-services function should govern issuers, request controls, policy, automation, monitoring, and emergency replacement. Security should govern key protection, logging, exceptions, and investigation. Procurement and architecture should prevent new platforms from creating unmanaged certificate islands.
\r\nAutomation should be idempotent, observable, and recoverable. Test what happens when enrollment fails, a deployment reaches only part of a cluster, a load balancer retains an old binding, a trust chain changes, or an application cannot reload a key without restart. Protect automation identities and private keys independently; faster deployment is not safer if one credential can replace certificates everywhere without strong authorization and logging.
\r\nKeep approved policy, an inventory reconciliation report, owner attestations, issuer and exception records, key-custody evidence, renewal and deployment logs, client-side validation, alerts, incident records, and results from a replacement exercise. Report unknown certificates, ownerless services, policy exceptions, failed automation, incomplete deployments, and overdue remediation without inventing a universal target. Leadership should set tolerances from business impact and recovery capability.
\r\nThis scope deliberately differs from DSE’s device-specific article on camera HTTPS and 802.1X certificates. The goal here is an enterprise service spanning technologies, with evidence that routine renewal and urgent cryptographic change can both be completed safely.
\r\nDSE recommends reconciling public certificate-transparency observations with the internal register while recognizing that private certificates will not appear there. Where architecture warrants it, scan from more than one network perspective and verify that retired services no longer present unexpected certificates. Every discovery record should state its scope, date, and known blind spots.
\r\n