SSL certificates

SSL and TLS certificates are the foundation of encrypted communication between websites and users. For Canadian businesses operating in fintech, healthcare, or e-commerce, choosing the right certificate type directly affects regulatory compliance, customer trust, and data security posture.

What an SSL/TLS Certificate Actually Does

The term "SSL certificate" is still widely used, but the protocol itself has been replaced by TLS 1.2 and TLS 1.3. The certificate performs two distinct functions: it establishes an encrypted channel between server and client, and it cryptographically proves the identity of the server presenting it.

When a browser connects to a secured site, it performs a TLS handshake. During this process, the server presents its certificate, the browser verifies it against a trusted Certificate Authority (CA), and both sides negotiate a session key. The entire handshake takes under 50 milliseconds on a modern connection.

What the certificate contains:

• Public key of the domain owner
• Domain name(s) the certificate covers
• Issuing Certificate Authority identity
• Validity period (typically 1 year; reducing to 47 days by 2026 under CA/Browser Forum ballot SC-081)
• Certificate serial number and signature algorithm

Certificate Types and When to Use Each

Not all certificates provide the same level of identity assurance. The three standard validation levels differ in what the CA verifies before issuance.

For Canadian fintech companies operating under OSFI guidelines or processing payments under PCI DSS, OV or EV certificates are expected at minimum. A DV certificate on a banking portal does not satisfy the identity assurance requirements under FINTRAC or PIPEDA-adjacent controls.

Multi-Domain, Wildcard, and SAN Certificates

Beyond validation levels, certificate coverage structure matters for organizations managing multiple subdomains or properties.

Wildcard certificates cover one domain and all direct subdomains: a single wildcard for *.example.ca covers app.example.ca, api.example.ca, and login.example.ca, but not sub.app.example.ca.

SAN (Subject Alternative Name) certificates list multiple distinct domains in a single certificate. A single SAN certificate can cover example.ca, example.com, and portal.examplefinance.ca simultaneously, reducing management overhead.

Single-domain certificates remain appropriate for isolated services with no subdomain dependencies.

Wildcard certificates carry a known security tradeoff: if the private key is compromised, every subdomain it covers is exposed. Enterprise security teams often prefer individual OV or EV certificates per subdomain for sensitive services despite the higher administrative cost.

TLS 1.3 vs TLS 1.2: What Canadian Operators Need to Know

TLS 1.3 became the recommended standard after RFC 8446 publication in 2018. By 2026, most Canadian federal agencies and major financial institutions have deprecated TLS 1.0 and 1.1 entirely, and many enforce TLS 1.3 as the preferred version.

Key differences:

Canadian organizations subject to the Communications Security Establishment (CSE) ITSP.40.062 guidance on TLS are expected to support TLS 1.3 and disable deprecated ciphers. Hosting providers that still default to TLS 1.2-only configurations create compliance exposure.

eIDAS, PSD2, and QWAC Certificates: The European Standard Arriving in Canada

QWAC stands for Qualified Website Authentication Certificate. It is defined under the European Union's eIDAS regulation (and updated under eIDAS 2.0) as the highest-assurance certificate type for web authentication, requiring issuance from a Qualified Trust Service Provider (QTSP).

While eIDAS is an EU regulation, its influence extends to Canadian fintech operations in two concrete scenarios:

1. Canadian financial institutions with EU operations or EU-facing APIs must comply with PSD2 Strong Customer Authentication requirements, which mandate QWAC certificates for payment service providers connecting to bank APIs.
2. Cross-border digital identity frameworks are increasingly referencing eIDAS 2.0 standards as a model, including within the Digital Charter Implementation Act discussions in Canada.

Under PSD2 Article 98 and the related EBA Regulatory Technical Standards, third-party payment providers (TPPs) must use QWAC and QSeal certificates when communicating with account-holding banks. A standard OV or EV certificate does not satisfy this requirement.

QWAC certificates embed specific QCStatement extensions that mark them as qualified under eIDAS. They must be issued by a CA that appears on an EU member state's Trusted List (the "TSL").

Differences between QWAC and standard EV:

Certificate Lifecycle Management for Canadian Enterprises

The CA/Browser Forum's ballot SC-081 reduces maximum certificate validity to 47 days by late 2026. This means organizations that manually renew certificates will face renewal cycles roughly every six weeks instead of annually. The operational impact is significant for teams managing more than 10 certificates.

Common failure points in certificate lifecycle management:

• Expired certificates in production: In 2024, over 38% of certificate-related outages reported by enterprise security teams were caused by untracked expiry, according to Keyfactor's State of Machine Identity Management report.
• Shadow certificates: Certificates issued outside the knowledge of the central IT team, often by developers for test environments that later enter production.
• Key reuse on renewal: Reusing private keys across certificate cycles negates forward secrecy gains.

Recommended lifecycle controls:

1. Maintain a certificate inventory with expiry dates, issuing CA, coverage scope, and responsible owner
2. Automate renewal using ACME protocol where the CA supports it (Let's Encrypt, ZeroSSL, and several commercial CAs)
3. Set renewal alerts at 30 days, 14 days, and 7 days before expiry
4. Rotate private keys on every renewal, not just on compromise
5. Log all certificate issuance events to your SIEM for audit trail

Canadian Compliance Context: PIPEDA, OSFI, and PCI DSS

Three regulatory frameworks directly touch TLS certificate requirements for Canadian organizations.

PIPEDA (Personal Information Protection and Electronic Documents Act) does not specify TLS versions explicitly but requires "appropriate security safeguards." Transmitting personal data over TLS 1.0 or without a valid certificate would be difficult to defend as appropriate under a breach investigation.

OSFI Guideline B-10 (Third-Party Risk Management, updated 2023) requires federally regulated financial institutions to assess the cryptographic controls of their service providers, including whether those providers use current TLS standards.

PCI DSS v4.0 (effective March 2024, mandatory by March 2025) requires TLS 1.2 at minimum, with TLS 1.3 strongly recommended. It also requires that certificates protecting cardholder data environments come from trusted CAs, and that certificate management is documented and auditable.

For Canadian merchants and payment processors, the intersection of PCI DSS and OSFI guidance means a documented certificate inventory is not optional.

Choosing a Certificate Authority for Canadian Operations

Canadian businesses should evaluate CAs on four criteria:

All major commercial CAs (Sectigo, GlobalSign, DigiCert) maintain roots in Mozilla, Microsoft, Apple, and Google trust stores. The differentiator for Canadian fintech is QTSP status and the ability to issue eIDAS-compliant certificates, which not all CAs hold.

Verify a CA's QTSP status by checking the EU Trusted Lists Browser at the European Commission's eSignature portal, or by requesting the CA's Certificate Policy and Certification Practice Statement (CP/CPS) documents, which are public disclosures required under CA/Browser Forum standards.