Certificate authorities

A Certificate Authority (CA) is the organization that issues, signs, and revokes digital certificates used to authenticate websites, services, and identities online. Without a trusted CA in the chain, browsers reject connections, APIs fail mutual authentication, and regulatory compliance breaks down. In Canadian fintech and government digital identity contexts, the CA you choose directly affects your PSD2 readiness, eIDAS alignment, and TLS posture.

What a Certificate Authority Actually Does

A CA performs three core functions that most explanations collapse into one: it verifies the identity of the certificate applicant, it cryptographically signs the certificate binding that identity to a public key, and it maintains the revocation infrastructure so that compromised certificates stop being trusted within minutes rather than days.

The trust model depends on a hierarchy:

• Root CA — the ultimate trust anchor, stored in operating system and browser trust stores (Mozilla NSS, Microsoft CTL, Apple Root Program)
• Intermediate CA — signs end-entity certificates; isolates the root from day-to-day issuance
• End-entity certificate — issued to a domain, organization, or individual; expires and must be renewed

Root CAs rarely sign certificates directly. The intermediate layer limits blast radius if an intermediate is compromised: the root can revoke just that intermediate rather than every certificate ever issued.

Types of Certificates a CA Issues

The 47-day maximum for publicly trusted TLS certificates comes from CA/Browser Forum Ballot SC-081, which phases in between 2025 and 2029 with the 47-day cap effective March 2029. Planning certificate automation now prevents operational failures at that deadline.

How Certificate Validation Works Step by Step

1. Applicant generates a key pair — private key stays on the applicant's infrastructure; public key goes into the Certificate Signing Request (CSR).
2. CA receives the CSR — verifies domain control via DNS TXT record, HTTP file, or email (DV); adds org identity checks for OV/EV.
3. CA signs the certificate — binds the public key to the verified identity using its intermediate CA private key.
4. Certificate is published to Certificate Transparency (CT) logs — mandatory for all publicly trusted TLS certs since 2018.
5. Revocation infrastructure is updated — OCSP responders and CRLs reflect the new certificate's serial number as valid.
6. Relying parties verify — browsers, API gateways, and mobile apps check the chain, CT log inclusion, and revocation status before completing the handshake.

Why CA Trust Stores Determine Everything

Your certificate is only trusted if the issuing CA's root appears in the trust store of the client making the connection. There are four major trust programs that matter for Canadian operators:

• Mozilla NSS — used by Firefox and most Linux distributions
• Microsoft CTL — used by Windows, Edge, and any Windows-native application
• Apple Root Program — used by Safari, iOS, macOS apps
• Google Chrome Root Program — Chrome manages its own root store separately from the OS since 2022

A CA that is removed from any one of these programs causes immediate connection failures for that client base. Mozilla has removed CAs for failure to comply with audit requirements; DigiNotar (2011) and TrustCor (2022) are the most widely cited cases. When evaluating a CA, check its current audit status: WebTrust for CAs and ETSI EN 319 411 are the two dominant audit frameworks.

eIDAS, QWAC Certificates, and PSD2 Compliance

For Canadian fintechs operating in or connecting to European markets, eIDAS introduces a category of certificate that goes beyond standard TLS: the Qualified Website Authentication Certificate (QWAC).

What makes a QWAC different from an EV certificate:

Under PSD2, third-party payment providers (TPPs) must present a QWAC or eIDAS-compliant certificate when calling bank APIs. A standard EV certificate does not satisfy this requirement. Canadian payment providers connecting to European open banking infrastructure need certificates from a QTSP listed on an EU Member State's Trusted List (TL).

Certificate Lifecycle Management: The Part Most Teams Get Wrong

Issuing a certificate is straightforward. Managing hundreds or thousands of them across cloud, on-premise, and partner environments is where organizations fail.

Common failure points:

• Manual renewal tracking in spreadsheets — leads to expired certificates and outages; a 2024 survey found certificate-related outages cost enterprises an average of $15,000 per hour
• No inventory of non-web certificates — S/MIME, code signing, and client certs are often invisible to the team that manages TLS
• Private key reuse across renewals — generates the same key for years, increasing the window of exposure if the key is ever compromised
• Ignoring CT log monitoring — rogue certificates issued for your domain appear in CT logs within minutes; monitoring for unexpected issuance is a basic security control

What automated certificate lifecycle management (CLM) covers:

• Discovery of all certificates across infrastructure
• Automated renewal via ACME protocol (Let's Encrypt, ZeroSSL, or private CA with ACME support)
• Private key rotation on every renewal
• Alerting on certificates expiring within 30, 14, and 7 days
• Integration with Kubernetes (cert-manager), Terraform, and CI/CD pipelines

Choosing a Certificate Authority: Criteria That Actually Matter

Generic advice says "pick a trusted CA." Here is what the decision actually involves for a Canadian fintech or enterprise:

Certificate Authority in Zero-Trust Architecture

Modern zero-trust networks rely on mutual TLS (mTLS) for service-to-service authentication, which means a private CA — not a public one — issues certificates to internal workloads.

Public CA vs. Private CA for internal use:

• Public CA certificates for internal services expose your internal hostnames to CT logs (a privacy and security issue)
• Private CAs (HashiCorp Vault PKI, AWS Private CA, Microsoft ADCS, or a dedicated internal CA) issue certificates that never appear in public CT logs
• Private CA certificates are not trusted by external clients by default — they require distribution of the private root to managed devices

A zero-trust architecture typically uses both: a public CA for external-facing TLS, a private CA for internal mTLS between microservices, and a separate CA for device identity certificates issued through an MDM.