Multi-domain (SAN) certificates: one certificate for multiple domains

A multi-domain TLS certificate is a single X.509 certificate whose Subject Alternative Name (SAN) extension contains multiple identities the certificate can represent. For public TLS certificates, those identities are usually DNS hostnames such as www.yourdomain.com, api.yourdomain.com, and shop.yourdomain.net.

A client accepts the certificate for a connection only when the requested server name matches an appropriate identity in the certificate, and the rest of the certificate validation process succeeds.

DigiCert markets multi-domain certificates as SAN certificates and currently supports configurations with up to 250 domain names, depending on the selected product, account configuration, pricing, and applicable certificate-policy constraints.

Note: SAN is a certificate name-binding mechanism. It is not the same thing as SNI, and it does not inherently require every hostname to share one server, one IP address, or one deployment target.

When does a SAN certificate make sense?

A SAN certificate is useful when multiple known identities should intentionally share one certificate lifecycle. Common examples include:

• A defined set of hostnames across different base domains, such as www.yourdomain.com and portal.example.net.
• Several related services that terminate TLS on the same load balancer, reverse proxy, gateway, or other controlled termination tier.
• Environments where explicit hostname scope is preferable to wildcard coverage.
• Multi-domain OV or EV deployments where the required product and validation model support the requested names.
• Migration or consolidation scenarios where reducing the number of independently managed certificate objects is operationally valuable.

Do not choose a SAN certificate solely to reduce certificate count. The larger the name set and the broader the certificate/key distribution, the larger the potential blast radius of expiration, revocation, deployment error, or private-key compromise. Sometimes several smaller certificates are the safer operational design.

SAN, wildcard, and separate certificates solve different problems

• Multi-domain SAN — Best fit: known names, including names across different base domains. Strength: explicit scope with one certificate lifecycle. Trade-off: one certificate event can affect every included name.
• Wildcard — Best fit: many first-level subdomains under one domain. Strength: automatically matches qualifying subdomains without listing each one. Trade-off: broader namespace and key-sharing risk if reused widely; does not match deeper levels.
• Separate certificates — Best fit: strong isolation, separate ownership, different security boundaries. Strength: smallest practical blast radius and independent keys/lifecycles. Trade-off: more certificate objects and deployment workflows to manage.

How hostname matching works

Modern TLS clients compare the server name they are connecting to with identities in the certificate, primarily the SAN extension. A SAN certificate covers only the identities actually encoded in the certificate, subject to normal hostname-matching rules.

• If www.yourdomain.com is present as a SAN, the certificate can be valid for www.yourdomain.com.
• A SAN entry for yourdomain.com does not automatically cover www.yourdomain.com.
• A wildcard SAN such as *.yourdomain.com follows wildcard matching rules and is different from an explicit SAN such as api.yourdomain.com.
• Adding more SANs does not change which services actually possess, present, or use the certificate; deployment remains a separate lifecycle step.

How domain control validation works for SAN certificates

Before a publicly trusted TLS certificate is issued, the CA must establish authorization or control for every requested DNS identity under the CA/Browser Forum Baseline Requirements. That does not necessarily mean one completely separate manual validation transaction for every SAN.

In DigiCert CertCentral, the validation behavior depends on certificate type, DCV method, validation scope, and whether a qualifying validation is already current:

• OV and EV certificates can reuse current domain validation within the permitted reuse period. As of 2026, DigiCert supports a 199-day maximum reuse period.
• DV certificate orders require domain validation as part of each order and do not use CertCentral domain prevalidation/reuse in the same way as OV and EV orders.
• CertCentral can be configured to submit base domains or exact domain names for validation in supported workflows. Validating at an authorized parent/base-domain scope can cover qualifying subordinate names, while some methods validate only the exact FQDN.
• New or unvalidated domains added during a reissue must complete applicable DCV before the reissued certificate can be issued.

Why SAN certificates are not the same as SNI

SAN certificates and SNI address different parts of HTTPS virtual hosting. A SAN certificate defines which names one certificate can represent, while SNI lets a server select the appropriate certificate for the hostname the client requests. Two common architectures are:

• One SAN certificate for several sites — the server can present the same certificate for all of the covered hostnames. SAN lists the names that the one certificate is valid for; SNI is not required merely to choose among certificates because there may be only one certificate.
• Different certificates on one IP address — with SNI, the client sends the intended server name early in the TLS handshake so the server can select the appropriate certificate. Each selected certificate can itself have one or many SANs. SNI performs certificate selection; SAN performs name authorization/matching.

This distinction matters operationally. A SAN certificate consolidates names, while SNI allows certificate isolation without requiring a dedicated IP address per hostname on modern clients and servers.

Can you add SANs after issuance?

For current DigiCert multi-domain TLS products, SAN changes are performed through reissue. DigiCert supports reissues for multi-domain certificates, but adding SANs is not universally free. Additional SANs can create additional charges depending on the product, plan, and remaining coverage.

• A reissue requires a new CSR and therefore should use a new key pair under DigiCert's current reissue guidance.
• New, unvalidated domains must complete applicable DCV before the reissue can be completed.
• Changing or removing SANs can trigger revocation of the earlier certificate and its duplicates/reissues under current CertCentral behavior. Plan deployment of the replacement before making disruptive name changes.
• The application or load balancer must still receive and begin presenting the reissued certificate; reissue does not update endpoints on its own.

Security and operational considerations

• Expiration, revocation, misconfiguration, or private-key compromise can affect every service that depends on the same certificate instance.
• Sharing one certificate and private key across unrelated systems increases the number of locations where that key must be protected. Use separate certificates and keys when services cross trust boundaries.
• A certificate used by multiple teams or applications needs a clearly assigned owner and a coordinated process for changes, renewal, and incident response.
• Names in publicly trusted certificates are generally visible in Certificate Transparency logs, so SAN entries should not be treated as private inventory metadata.
• Public issuance remains subject to applicable CAA authorization as well as successful domain control validation.
• As of 2026, DigiCert's maximum public TLS validity is 199 days, with additional industry reductions scheduled. Consolidating names does not remove the need for reliable automated renewal and confirmed deployment.

Choosing SAN versus wildcard versus separate certificates

• Are the names known and relatively stable? — SAN can be a good fit when the set is explicit and controlled.
• Do the names cross base domains? — SAN is appropriate; a single wildcard cannot cover unrelated base domains.
• Do services have different owners or security boundaries? — prefer separate certificates/keys unless there is a deliberate reason to share a lifecycle.
• Do you need EV? — DigiCert supports EV multi-domain certificates; ordinary EV wildcard certificates are not permitted for public DNS names.
• Will one change affect too many services? — split the SAN set before automating broadly.
• Is the main goal one-IP hosting? — use SNI architecture; SAN consolidation is optional, not required.

Where DigiCert fits

DigiCert supports multi-domain public TLS certificates and provides certificate-lifecycle capabilities for discovering, issuing, renewing, deploying, and governing certificates across supported environments. The right automation pattern depends on where TLS terminates and how certificates are stored and bound.

• CertCentral supports DigiCert public TLS ordering, validation, reissue, renewal, and multi-domain certificate management.
• Trust Lifecycle Manager can provide broader inventory, policy, and automation capabilities across supported public and private CA sources and deployment targets.
• ACME, agents, sensors/connectors, APIs, and platform-native integrations are different automation patterns; the appropriate choice depends on the target environment.
• Regardless of method, mature lifecycle management should verify deployment success at the live service rather than treating CA issuance as the outcome.

Supplemental resources

• What is a Multi-Domain (SAN) Certificate?
• DigiCert Multi-Domain Certificates
• Add SANs to your multi-domain TLS/SSL certificate
• Domain validation requirements and reuse periods
• CertCentral domain validation scope settings
• CA/Browser Forum TLS Baseline Requirements
• End of 397-day public TLS/SSL certificates

Frequently asked questions