Certificate management

Certificate management is the process of issuing, tracking, renewing, and revoking digital certificates across an organization's infrastructure. For Canadian businesses operating in fintech, banking, or regulated industries, poor certificate management is not an abstract risk — it causes outages, failed audits, and broken API integrations. This guide covers what certificate management actually involves, where teams typically fail, and what a functional lifecycle looks like in 2026.

What Certificate Management Covers

Certificate management is broader than renewing SSL certificates once a year. It spans every digital certificate in your environment: TLS/SSL certificates for web servers and APIs, client authentication certificates, code signing certificates, document signing certificates, and qualified certificates under frameworks like eIDAS and PSD2.

Each type has different issuance requirements, validation levels, and renewal timelines. Managing them manually across dozens or hundreds of endpoints is where most organizations accumulate risk.

Why Certificate Lifecycles Are Getting Shorter

The CA/B Forum voted to reduce maximum TLS certificate validity to 47 days by 2027, with phased reductions already underway in 2026. Apple, Google, and Mozilla have enforced shorter lifespans through their root programs ahead of the formal deadline.

What this means in practice:

• Organizations that renewed certificates annually now face 7-8 renewals per certificate per year
• Manual renewal workflows break under this cadence
• Automation via ACME protocol or CA-provided APIs is no longer optional for most environments
• Certificate expiry monitoring must operate in near-real-time, not weekly scans

For Canadian organizations with large server estates or multi-cloud deployments, this shift requires dedicated tooling or managed certificate services.

Core Components of a Certificate Management System

A functional certificate management system addresses five operational areas:

1. Discovery Before you can manage certificates, you need to know where they are. Discovery tools scan IP ranges, DNS records, and cloud provider APIs to find all active certificates, including ones issued by shadow IT or deprecated internal CAs.

2. Inventory A centralized inventory records certificate metadata: subject, issuer, expiry date, algorithm, key length, deployment location, and owner. Without this, teams respond to expiry alerts reactively instead of proactively.

3. Issuance and enrollment Automated issuance connects your infrastructure to a CA via ACME, REST APIs, or SCEP. This removes manual CSR generation and copy-paste errors from the process.

4. Renewal and rotation Automated renewal triggers re-issuance 30–60 days before expiry, depending on your buffer tolerance. Rotation pushes the new certificate to the correct endpoint without manual intervention.

5. Revocation and reporting When a private key is compromised or a certificate is no longer needed, revocation must happen immediately. Reporting supports compliance audits, showing certificate status, renewal history, and policy adherence.

Certificate Management in Fintech and Open Banking

Canadian fintech companies operating under open banking frameworks face specific certificate requirements that go beyond standard TLS.

QWAC (Qualified Website Authentication Certificate) is required for PSD2-compliant API access in jurisdictions adopting eIDAS. A QWAC identifies the payment institution and is issued by a Trust Service Provider (TSP) under eIDAS-aligned rules. It authenticates the institution in machine-to-machine API calls between banks and third-party providers.

QSealC (Qualified Electronic Seal Certificate) is used to sign API messages, providing non-repudiation for data transmitted between financial institutions and TPPs.

Key differences between standard TLS and QWACs:

For Canadian organizations building cross-border fintech products that touch EU markets or UK open banking, QWAC issuance and lifecycle management is a compliance requirement, not a best practice.

Common Certificate Management Failures

The following failures appear repeatedly in post-incident reports and compliance audits:

Expiry-caused outages A certificate expires because no one received the renewal alert, or because the alert went to a mailbox no one monitors. Services go offline. Recovery time depends on how quickly the team can generate, validate, and deploy a replacement.

Algorithm deprecation SHA-1 is long deprecated, but environments with long-lived internal certificates still carry it. RSA-2048 is under pressure from NIST's post-quantum migration guidance. Inventory systems that do not flag algorithm risk leave organizations exposed.

Wildcard certificate sprawl Wildcard certificates are convenient but create blast-radius problems. A single compromised private key invalidates authentication across every subdomain covered by that certificate. Revocation of a wildcard certificate requires reissuance across all deployments simultaneously.

Orphaned certificates Decommissioned servers sometimes leave certificates running without owners. These are not renewed, not monitored, and create confusion during audits about whether an IP is still active infrastructure.

Multi-cloud drift Organizations running AWS, Azure, and GCP simultaneously often have separate certificate stores in each environment. AWS Certificate Manager does not sync with Azure Key Vault. Certificates issued through cloud-native tools may not appear in a centralized inventory.

Automation Protocols: ACME, SCEP, EST, and REST

ACME is the default choice for web-facing TLS certificates. For internal PKI, SCEP or EST are more common. Fintech environments using QWACs typically rely on REST APIs provided by the TSP, since ACME is not yet standardized for qualified certificates.

Certificate Management for Internal PKI

Organizations running Microsoft Active Directory Certificate Services (ADCS) or open-source alternatives like Dogtag, EJBCA, or Vault PKI manage an additional layer of complexity: the root and intermediate CA infrastructure itself.

Internal PKI responsibilities include:

• Root CA key ceremony documentation and hardware security module (HSM) storage
• CRL (Certificate Revocation List) publication and OCSP responder uptime
• Intermediate CA rotation every 5–10 years
• Audit log retention aligned with compliance requirements (PIPEDA, SOC 2, PCI-DSS)

For Canadian organizations subject to PIPEDA or provincial privacy legislation, internal CA audit logs may be subject to data residency requirements. Certificates used to authenticate access to personal data fall within the scope of breach notification obligations if the private key is compromised.

Compliance Frameworks That Touch Certificate Management

The NIST post-quantum cryptography standards (FIPS 203, 204, 205) finalized in 2024 have driven certificate management platforms to begin supporting hybrid certificates — certificates that carry both a classical algorithm (RSA or ECDSA) and a post-quantum algorithm (ML-KEM, ML-DSA) simultaneously. Canadian federal agencies and financial institutions are expected to begin hybrid certificate deployments between 2026 and 2028.

Building a Certificate Management Policy

A certificate management policy defines rules before incidents happen. Minimum policy components:

• Approved certificate types and issuers by use case
• Maximum allowed key lengths and algorithms (flag RSA-2048 for review by 2027)
• Renewal lead time thresholds (recommended: 60 days for externally-facing, 30 days internal)
• Private key storage requirements (HSM for code signing and CA certificates)
• Revocation procedure and maximum revocation response time (24 hours for compromise)
• Ownership assignment: every certificate must have a named team or individual owner
• Audit review frequency (quarterly minimum for regulated environments)

Without a written policy, certificate management defaults to reactive behaviour: someone notices an expired cert, scrambles to fix it, and the root cause — no ownership, no monitoring — remains.