SAN (Subject Alternative Name) Certificates: What They Are, When to Use Them, and How to Add SANs

What is a SAN?

A Subject Alternative Name (SAN) lets one SSL/TLS certificate protect multiple, distinct hostnames (e.g., example.com, www.example.com, example.net, shop.example.co.uk) under a single cert.

SAN vs. Wildcard

• SAN covers different hostnames and domains.
• Wildcard covers many subdomains of one domain (e.g., *.example.com) but not other domains like example.net.

When should I choose SAN?

Choose a SAN certificate if you need to secure:

• Multiple sites/domains (e.g., example.com, example.net, example.org)
• Different hostnames that aren’t all subdomains of a single domain
• A mix of root and subdomains (e.g., example.com, shop.example.com, example.net)

Choose a Wildcard if you only need to secure subdomains of one domain (e.g., api.example.com, cdn.example.com, mail.example.com).

Product availability: Not all SSL products include SAN support. Check our pricing page and sort by “SAN support.”
Note: This article does not apply to QuickSSL Premium with SAN, which has unique behavior and terms.

Before you start

• You’ll need access to your server to generate a new CSR and private key.
• Plan your full list of hostnames. You should include every hostname you want covered now (and ideally near-term) to minimize future reissues.
• IP addresses in the Common Name or SANs are not supported.

Example SAN list (CSR)

Common Name (CN): example.com Subject Alternative Names:  DNS: example.com  DNS: www.example.com  DNS: example.net  DNS: shop.example.co.uk

How to add SANs to an existing certificate

Step 1 — Generate a new CSR/private key

• A new CSR is required whenever you add or change SANs.
• The CSR must include all hostnames you want covered (existing + new).
• Keep the Common Name (CN) the same as the original certificate.
• Follow your server’s documentation for adding SANs (look for “SubjectAltName” / “SAN” in the CSR configuration).

Tip: Many servers use an OpenSSL config with a [ alt_names ] section, e.g.:

[ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = example.net

Step 2 — Sign in to the certificate supplier portal

• If you need access instructions, see our certificate reissue article.

Step 3 — Reissue the certificate

• In the portal, select Reissue Certificate.
• Choose Edit & Add Additional Domains (often labeled Redeem).
• Paste the new CSR and list the SAN hostnames you’re adding (they should already be in the CSR).
• Complete any domain control validation (DCV) prompts if requested.

Step 4 — Notify OpenSRS Support (required for extra SANs)

Reach out to OpenSRS support with:

• Reseller username:
• Supplier order ID:
• Common Name (CN):

We’ll complete the order and charge for any additional SANs at the current price shown on the pricing page.

You don’t need to contact Support if your total SAN count doesn’t change (e.g., you replaced one SAN with another and the count is the same).

Frequently asked questions

Do I have to reissue for any SAN change?
Yes. Any change to SANs (add/remove/replace) requires a reissue with a new CSR that includes the full desired SAN set.

Will validation restart?
It can. Some changes trigger DCV again for added hostnames. Be ready to approve validation emails/DNS/file checks quickly.

How are costs handled?

• You pay per additional SAN as listed on the pricing page.
• If you swap a SAN (total SAN count unchanged), no extra SAN fee applies.

Can I secure IP addresses?
No. Certificates with a CN or SAN that is an IP address are not supported.

What about QuickSSL Premium with SAN?
This guide doesn’t apply to QuickSSL Premium with SAN. That product has its own rules—please refer to its dedicated article.

Quick decision guide

• I only need *.example.com subdomains → Wildcard
• I need example.com, example.net, and shop.example.co.uk → SAN
• I’m changing my SAN list → Generate new CSR → Reissue → (If SAN count increases) Email Support

Troubleshooting tips

• “Name missing” after reissue: Ensure the CSR actually includes all SANs. What’s in the CSR is what ends up on the cert.
• Validation stuck: Confirm you completed DCV for every new hostname.
• Portal won’t accept CSR: Check that the CN matches the original certificate and that the CSR key length and algorithm meet current requirements (e.g., RSA 2048+).
• Renewal coming up: Align SAN changes with renewal when possible to avoid multiple reissues.

Was this article helpful? If not please submit a request here