TLS certificates

TLS certificates are the technical foundation of secure web communication. In Canada, their role has expanded beyond basic HTTPS — financial institutions, government portals, and API-driven services increasingly require certificates that meet specific identity and compliance standards. This guide breaks down how TLS certificates work, what types exist, and what Canadian organizations need to consider in 2026.

What a TLS Certificate Actually Does

A TLS certificate does two things simultaneously: it encrypts the connection between client and server, and it proves the server's identity. Without the identity component, encryption alone is meaningless — a user could be sending encrypted data to the wrong server entirely.

The certificate contains a public key, the domain name, the issuing Certificate Authority (CA), and a validity period. When a browser connects to a site, it checks:

• Whether the certificate was signed by a trusted CA
• Whether the domain matches
• Whether the certificate has been revoked

If any check fails, the browser shows a warning. Modern TLS relies on version 1.3 (RFC 8446), which removes support for weak cipher suites and reduces handshake latency by eliminating one round-trip compared to TLS 1.2.

TLS Certificate Types by Validation Level

There are three validation levels. They differ not in encryption strength but in how thoroughly the CA verifies the applicant before issuing the certificate.

For most Canadian businesses operating in regulated industries — banking, insurance, fintech — OV or EV certificates are the practical baseline. A DV certificate does not confirm who owns the site, only that the applicant controlled the domain at issuance.

Certificate Formats by Coverage Scope

Beyond validation level, certificates differ in how many domains or subdomains they cover.

Single-domain certificates cover exactly one FQDN (e.g., api.example.ca). They are straightforward but become expensive and operationally complex when managing dozens of endpoints.

Wildcard certificates cover one domain and all its subdomains at one level (*.example.ca). They cannot cover api.staging.example.ca without a second wildcard. Wildcard certificates are not eligible for EV validation under current CA/Browser Forum rules.

Multi-domain (SAN) certificates list multiple specific domains in the Subject Alternative Name field. A single certificate can cover example.ca, example.com, and portal.example.ca simultaneously. This is the most flexible option for organizations running multiple properties.

TLS in Fintech: PSD2, Open Banking, and QWAC

In financial services, a standard OV or EV certificate is often insufficient. The Payment Services Directive 2 (PSD2) in the EU and its equivalents in Canadian open banking frameworks require a specific certificate type: the Qualified Website Authentication Certificate, commonly known as QWAC.

A QWAC is not just a certificate — it is a legally binding digital identity credential issued under strict regulatory frameworks. It combines TLS functionality with identity assertions that go beyond what standard CAs verify.

Key differences between a standard EV certificate and a QWAC:

For Canadian fintechs operating in or connecting to EU markets, QWACs issued by a Qualified Trust Service Provider are required for accessing bank APIs under PSD2. As of 2026, Canada's own open banking framework under the Financial Consumer Agency of Canada (FCAC) is moving toward similar certificate-based API authentication.

eIDAS and Digital Identity: What Canadian Organizations Need to Know

eIDAS (Electronic Identification, Authentication and Trust Services) is the EU regulation governing digital identity and trust services. Its updated version, eIDAS 2.0, expanded the scope to include mobile digital wallets and cross-border identity assertions.

While eIDAS is EU law, it directly affects Canadian companies in several scenarios:

• Accessing EU financial markets: Any Canadian PSP or fintech that connects to EU bank APIs needs eIDAS-compliant certificates
• Cross-border data exchange agreements: Some bilateral agreements between Canada and EU member states reference eIDAS compliance for document authenticity
• Multinational clients: Enterprise clients with EU operations may contractually require their vendors to hold eIDAS-compliant credentials

eIDAS 2.0, adopted in 2024 and in phased implementation through 2026, introduced the European Digital Identity Wallet (EUDI Wallet), which relies on qualified certificates for signing and authentication. Canadian identity providers seeking interoperability with this system need to understand the certificate trust chains involved.

Certificate Lifecycle Management: The Operational Reality

Acquiring a certificate is only the beginning. The operational burden comes from managing it over time. In 2026, the CA/Browser Forum's proposed maximum certificate validity has dropped to 47 days for new issuances, down from the previous 398-day limit. This accelerates the need for automated renewal.

Key lifecycle events that require active management:

• Initial issuance (domain validation, documentation, key generation)
• Periodic renewal (before expiry; automated with ACME protocol for DV certificates)
• Revocation (if private key is compromised or domain ownership changes)
• Certificate transparency log monitoring (all publicly trusted certificates are logged)

Tools commonly used for automation:

Organizations running more than 10 certificates without automation are accumulating operational risk. An expired certificate on a payment API or authentication endpoint can cause immediate service disruption.

Choosing a Certificate Authority: Factors That Matter

Not all Certificate Authorities are equivalent. For Canadian businesses, the relevant criteria include:

Trust store inclusion: The CA's root must be in the trust stores of major browsers (Chrome, Firefox, Safari, Edge) and operating systems (Windows, macOS, Android, iOS). A certificate from a CA not in these stores will cause browser errors regardless of technical validity.

Geographic infrastructure: For latency-sensitive OCSP (Online Certificate Status Protocol) checks, a CA with infrastructure in North America reduces validation time. Some CAs use CDN-distributed OCSP responders.

Support for Canadian legal entities: OV and EV issuance requires document verification. A CA familiar with Canadian corporate registries (federal and provincial) will process these faster than one unfamiliar with Canadian documentation formats.

QTSP status for QWAC issuance: Only Qualified Trust Service Providers can issue QWACs. Standard commercial CAs cannot issue them, even if they offer EV certificates.

Revocation infrastructure: Check that the CA supports both CRL (Certificate Revocation List) and OCSP. Some modern deployments are moving toward OCSP Stapling to reduce CA dependency at connection time.

Implementation Checklist for Canadian Organizations

Before deploying a TLS certificate, verify the following:

• [ ] Determine the correct validation level based on regulatory context (DV / OV / EV / QWAC)
• [ ] Identify all domains and subdomains that need coverage
• [ ] Generate a 2048-bit RSA or 256-bit ECDSA private key — store it securely, never transmit it
• [ ] Submit CSR (Certificate Signing Request) with accurate organization details matching registry records
• [ ] Configure server to serve the full certificate chain (leaf + intermediate + root)
• [ ] Enable HTTP Strict Transport Security (HSTS) after deployment
• [ ] Set up automated monitoring for certificate expiry (alert at 30 days, 14 days, 7 days)
• [ ] Enable Certificate Transparency monitoring to detect mis-issuance

Common Implementation Errors

Serving an incomplete certificate chain: The server must send the leaf certificate and all intermediate CA certificates. Missing intermediates cause errors on mobile devices that do not cache intermediate CAs.

Mismatched SANs: Modern browsers ignore the Common Name (CN) field and validate only against Subject Alternative Names. A certificate with example.ca in CN but not in SAN will fail validation.

Using SHA-1 signed certificates: SHA-1 has been deprecated since 2017. Any certificate signed with SHA-1 will be rejected. Use SHA-256 or higher.

Ignoring certificate transparency alerts: Public CT logs record every issued certificate. Monitoring services can alert you when a certificate is issued for your domain by an unexpected CA — this is an early indicator of a man-in-the-middle or supply chain attack.