Multi-domain certificates

A multi-domain certificate — also called a SAN certificate or UCC (Unified Communications Certificate) — lets you secure multiple hostnames under a single TLS credential. Instead of managing five separate certificates for five domains, you bind them into one issuance with one expiry date and one renewal workflow. For Canadian organizations running split-domain infrastructure or operating across several branded properties, this directly reduces operational overhead and certificate-related outages.

What "Multi-Domain" Actually Means in TLS Terms

The mechanism behind multi-domain coverage is the Subject Alternative Name (SAN) extension in X.509 certificates. Each SAN entry adds a hostname the certificate is valid for. A certificate issued for portal.example.ca can also cover api.example.ca, payments.otherbrand.ca, and app.thirdproperty.com — all in one file.

Key structural facts:

• SANs can hold FQDNs, IP addresses, and email addresses
• The Common Name (CN) field is deprecated for hostname matching; browsers rely exclusively on SANs since RFC 2818
• Most commercial CAs cap SAN counts at 100–250 entries per certificate
• Each additional SAN beyond the base bundle is billed individually (typically CAD $15–40/SAN/year depending on validation tier)

Multi-Domain vs. Wildcard: Which One Solves Your Problem

These two certificate types are often confused. They solve different problems.

A wildcard *.payments.ca covers api.payments.ca and portal.payments.ca but not payments.ca itself (unless explicitly added) and not deep.api.payments.ca. Multi-domain fills the gaps wildcards cannot.

Validation Levels Available for Multi-Domain Certificates

Multi-domain certificates are available at all three validation tiers. The tier you choose affects what appears in the certificate's Subject field and how long issuance takes.

Domain Validation (DV)

• Automated DNS or HTTP challenge per SAN
• Issuance in minutes to hours
• No organizational identity in the certificate
• Appropriate for internal APIs, staging environments, dev portals

Organization Validation (OV)

• CA verifies legal existence of the organization against government registries
• In Canada: cross-referenced against Corporations Canada or provincial registrar data
• Issuance 1–3 business days
• Shows organization name in certificate details
• Standard choice for customer-facing web applications

Extended Validation (EV)

• Strictest vetting: legal, operational, and physical presence verification
• Each SAN domain must belong to the same verified legal entity
• Issuance 3–7 business days
• Previously triggered the green address bar (removed by browsers in 2019), but still provides organizational assurance in certificate inspection
• Required under some PSD2 technical standards for payment service providers

Multi-Domain Certificates in Fintech and PSD2 Compliance

Canadian fintech companies operating under FINTRAC oversight or integrating with European open banking frameworks under PSD2 face specific certificate requirements. This is where multi-domain certificates intersect with regulatory compliance.

Under PSD2 and eIDAS, payment service providers must use Qualified Website Authentication Certificates (QWACs) for their API-facing endpoints. A QWAC is an EV-class certificate issued by a Qualified Trust Service Provider (QTSP) under the eIDAS regulation. It can be issued as a multi-domain certificate to cover both the primary TPP dashboard and its API subdomain under a single credential.

Practical scenario:

• open-banking.fintechco.ca — customer-facing portal
• api.fintechco.ca — PSD2 API endpoint
• sandbox.fintechco.ca — developer testing environment

All three can appear as SANs in one OV or QWAC certificate, provided the CA has verified domain ownership and organizational control for each entry.

FINTRAC's 2024 guidance on digital identity verification for MSBs (Money Services Businesses) does not mandate a specific certificate type, but auditors increasingly flag expired or mismatched TLS credentials as a control deficiency during technology risk assessments.

Certificate Lifecycle Management at Scale

The operational argument for multi-domain certificates is strongest when you map out what certificate sprawl looks like at 20+ domains.

Problems with individual certificates per domain:

• Different expiry dates create staggered renewal windows
• Each certificate is a separate monitoring alert
• Multiple private keys increase key management complexity
• Cost per domain is higher than SAN pricing at volume

Consolidated multi-domain approach:

• Single renewal event
• One private key (or a small number of keys across cert groups)
• Unified monitoring endpoint
• Volume SAN pricing reduces per-domain cost

Example cost comparison for a 10-domain deployment (approximate CAD, 2026 pricing):

Pricing varies by CA and SAN pack structure. Most CAs sell base certificates with 3–5 SANs included, then charge per additional SAN.

How Issuance Works: Step-by-Step

1. Generate a CSR with all intended SANs listed in the Subject Alternative Name field. OpenSSL, Certbot, and most enterprise key management tools support multi-SAN CSR generation natively.

1. Submit to CA with validation proof. For DV, this is automated (DNS TXT record or HTTP file challenge per domain). For OV/EV, you submit organizational documents and the CA performs outreach verification.

1. CA validates each SAN independently. This is important: the CA must verify control or ownership of every domain listed. Adding a new SAN to an existing cert requires re-validation of that specific hostname.

1. Certificate issuance. The signed certificate contains all validated SANs in the extension field. You install the same certificate file on every server and load balancer that needs to present it.

1. Monitor expiry centrally. Set alerts at 60 days and 30 days before expiry. With a single cert covering critical infrastructure, a missed renewal affects all covered domains simultaneously.

Adding and Removing SANs During the Certificate Lifetime

Most CAs do not allow in-place SAN modification. To add a hostname mid-term, you typically reissue the certificate (generating a new certificate with the updated SAN list). The old certificate is revoked after the new one is deployed.

This has two operational implications:

• Plan SAN lists ahead of time. Adding a domain you forgot during a production incident is a reissuance cycle, not a quick edit.
• Reissuance is usually free within the certificate term for most CAs, but requires repeating domain validation for the new SAN.

Some CAs offer "SAN flex" pools where you pre-purchase SAN slots and activate them on demand without full reissuance. This is worth evaluating if your infrastructure changes frequently.

Wildcard SANs in Multi-Domain Certificates

You can combine wildcard entries and specific FQDNs within a single multi-domain certificate. For example:

• *.payments.ca (covers all subdomains of payments.ca)
• api.openbanking.ca (specific host on a different domain)
• portal.creditunion.ca (specific host on a third domain)

This hybrid approach is useful when one domain has unpredictable subdomain growth while others have fixed hostnames. Note that wildcard SANs are not available at EV validation level — EV requires explicit domain listing.

Common Deployment Mistakes

Mistake 1: Forgetting the bare domain. A certificate with only *.example.ca does not cover example.ca. Add the apex domain as an explicit SAN.

Mistake 2: Mismatched servers. The same certificate and private key must be installed everywhere the covered hostnames resolve. If api.example.ca points to a load balancer that has an older certificate, users will see a mismatch error regardless of what the new cert says.

Mistake 3: Over-consolidating. Putting 80 unrelated domains into one certificate creates a large revocation blast radius. If the private key is compromised, all 80 domains need immediate re-keying. Group certificates by security zone, not just by convenience.

Mistake 4: Ignoring CT logs. All publicly trusted certificates are logged in Certificate Transparency logs. Competitors and security researchers can enumerate your SAN list. Do not add internal hostnames that reveal infrastructure details to a public-trust certificate.