Add or Remove SANs on UCC SSL (Step-by-Step)

You launched new subdomains, retired a few microsites, and now your SSL setup is a mess. The cert still lists domains you’ve killed, and it doesn’t cover the ones your team just shipped. If you run a Unified Communications Certificate (UCC) or any multi-domain SAN SSL, this guide shows you exactly how to add or remove Subject Alternative Names (SANs) without downtime, without breaking redirects, and without confusing Google or customers.

A UCC SSL certificate, also known as a multi-domain or SAN (Subject Alternative Name) certificate, lets you secure multiple hostnames with one certificate. Instead of juggling separate certs for app.example.com, www.example.com, and example.net, you keep a single cert that lists all of them in its SAN field. That’s why UCCs are loved for Microsoft Exchange/Office servers and any stack that runs several hostnames behind a shared load balancer or CDN.

Not all SAN certs are the same. You can get DV (domain validated), OV (organization validated), or EV (extended validation) profiles. DV is fast and automated; OV/EV adds legal/org vetting and often human checks. All three can be SAN-enabled. The catch is management: when you add or remove SANs, you typically reissue the certificate, re-validate new domains, and reinstall. Planning matters.

How does this compare to a wildcard? A wildcard like *.example.com secures all first-level subdomains of a single domain. A SAN cert secures distinct hostnames across multiple domains. If your fleet spans different root domains (e.g., example.com, example.co.uk, example.io), SAN is your tool. If you mostly spin subdomains under one apex, a wildcard (or wildcard + SAN hybrid) might be simpler.

Adding SANs usually follows growth: new landing pages on fresh subdomains, geo-expansion on new TLDs, or vendor integrations that require a branded endpoint. Removing SANs typically follows consolidation: deprecating microsites, retiring test environments, or cleaning up a rebrand. In both cases, the goal is the same - encryption continuity, no scary browser warnings, and no cart or form-drop from trust errors.

From an SEO standpoint, expired or misconfigured certificates don’t directly de-rank you, but they nuke conversion and engagement. If Chrome throws a full-page red warning, users bounce. That hits behavioral signals and revenue. Redirect chains, HSTS, and canonicalization also matter - if you remove a SAN without cleaning redirects, you can strand crawlers and users on HTTP or non-canonical hosts.

Operationally, SAN changes are a reissue, not a simple edit. That means re-validation (DCV) for new domains, downloading the new cert bundle, and reinstalling on every endpoint (web servers, load balancers, proxies, CDNs). If you run multiple regions or clusters, multiply the steps. The good news: with a solid checklist and a maintenance window, it’s routine and safe.

First, understand Domain Control Validation (DCV). To add a new SAN, you must prove control. Your CA (certificate authority) will offer DNS TXT validation, HTTP file upload validation, or email validation. DNS is the most reliable at scale, HTTP is simple if you control the web root, and email is fine if you can receive email at admin/hostmaster/postmaster on the new domain.

Second, know the difference between reissue and renewal. Renewal extends the expiry date toward another year/term. Reissue replaces the certificate with the same expiry window (unless your CA also renews during reissue) but changes its SAN list or keys. Most SAN edits are a reissue; some CAs require you to purchase extra SAN “slots.” Read your vendor’s SAN capacity and pricing before you plan the change.

Third, track your private keys. If you generate a new CSR, you’ll get a new public/private key pair. That means every endpoint needs the matching private key. If you reissue using the existing CSR/key, you keep your current private key and only the public cert bundle changes - less redeploy friction. Security teams sometimes prefer new keys as a hygiene practice; ops teams prefer minimal redeploy. Decide deliberately.

Many teams inherit a UCC from years ago and keep adding SANs. That’s fine, but there’s a maintenance tax: manual DCV, manual reissue, and manual deploy. If you’re adding and removing hostnames quarterly, you should evaluate ACME automation (Let’s Encrypt, ZeroSSL, Buypass). With ACME, your stack can request, validate, and renew certificates automatically, including multi-domain SAN certs, often with DNS validation wired into your DNS provider API.

Automation isn’t for every org. If you require EV or OV with a specific enterprise CA, ACME may not match your compliance policies. If you run hardware security modules (HSM) or strict key custody, you may stick with a commercial CA and manual or scripted pipelines. But for most marketing and app workloads, ACME reduces human error and removes the “who has the latest cert?” Slack scramble.

There’s also the wildcard/ACME hybrid: keep a wildcard for broad subdomain coverage and supplement with SAN certificates for oddball domains or vendor-required hostnames. This can cut the number of SAN edits you make to a shared UCC and isolate risk when a subdomain is dynamic.

This is the generic pattern across most commercial CAs. Details vary by vendor UI, but the flow is stable. Aim for a short maintenance window even if you expect zero downtime - that keeps your deployment calm and reversible.

1) Inventory and capacity: List all hostnames currently covered, all endpoints serving the cert, and your CA’s SAN limit. Confirm you have available SAN “slots” or buy more. Capture the current cert, private key, chain, and server bindings for rollback.

2) Plan DCV: Choose DNS, HTTP, or email validation for each new hostname. If you control DNS via API, prefer DNS TXT. If a CDN or reverse proxy terminates TLS, HTTP DCV might terminate at the wrong layer - plan accordingly. Assign ownership for each validation step.

3) Generate CSR (optional): Decide whether to reuse your existing private key. If rotating keys, generate a new CSR with all current SANs plus the new ones. If retaining the key, your CA may support reissue without a new CSR. Keep key material secure; document storage and access.

4) Request reissue: In your CA portal, choose reissue/replace, add the new SANs, and submit the CSR if needed. Complete DCV for the new domains. Wait for the CA to sign and release the new certificate files (server cert, intermediates, bundle).

5) Deploy to staging: Install the new cert on a staging or canary target. Verify the certificate chain, hostname coverage, and TLS settings. Run SSL Labs (or similar) against the staging hostname to check for chain issues and legacy clients if you care about them.

6) Rotate in production: Roll out the new certificate across load balancers, web servers, and CDNs. Update IIS bindings or your Nginx/Apache cert file paths. Keep the old cert around until you confirm success. Use progressive rollout if your traffic is heavy.

7) Validate live: Hit each hostname over HTTPS, confirm no mixed-content warnings, check HSTS headers, and run a quick crawl to ensure redirects and canonical tags are intact. Monitor error rates and TLS handshakes in your logs for the next hour.

Validation options: DNS, HTTP, or email - which to pick and why

DNS TXT DCV is the most reliable for SAN fleets. You create a unique TXT record per hostname with a token the CA gives you. It avoids edge termination traps and works even if the site isn’t live yet. The downside: DNS propagation can delay validation, so reduce TTLs a few hours ahead.

HTTP file DCV is fast if you control the webroot and have a straightforward path from the internet to the origin. For sites behind a CDN, confirm that the .well-known/acme-challenge path (or your CA’s equivalent) isn’t cached or blocked. If you’re adding a SAN that points to a vendor platform, you may not control that webroot - use DNS instead.

Email DCV is fine for small orgs if you can receive at admin@, hostmaster@, or postmaster@ on the domain. It’s the least scriptable and breaks if your IT blocks role accounts or forwarding. At scale, prefer DNS.

Server installs: IIS/Exchange, Nginx/Apache, cPanel/Plesk - quick notes

On IIS/Exchange, import the .pfx with the private key into the machine store, then update the site binding to the new certificate. If you rotated keys, ensure the private key permissions include the IIS user. Restart isn’t always needed, but plan a recycle to be safe.

On Nginx/Apache, place the new cert and key files on disk, update ssl_certificate and ssl_certificate_key (Nginx) or SSLCertificateFile, SSLCertificateKeyFile, and SSLCertificateChainFile (Apache), then reload gracefully. Keep old files for rollback until you complete validation.

On cPanel/Plesk, use the UI to upload the certificate and assign it to the domains. Remember: if many SANs terminate on the same server, make sure SNI is enabled and that each vhost points to the updated certificate bundle.

Removing a SAN is also a reissue, but the real work is decommissioning the hostname. Before you yank it from the cert, ensure the hostname either redirects permanently (301) to your target or is fully retired at DNS with no residual traffic. If HSTS was set for that hostname, dropping TLS can lock users out unless you keep HTTPS online for the redirect or remove the HSTS policy ahead of time.

Plan the sequence: update redirects on the old host to your new canonical, keep HTTPS available long enough for crawlers and users to follow, then reissue the cert without the SAN, and finally remove DNS records once traffic flatlines. Watch server logs and analytics to confirm no long-tail hits before final removal.

Document the removal reason, date, and replacement target. This is useful for audits and prevents accidental resurrection. If a team revives an older marketing URL months later, you want a clear paper trail explaining why it’s no longer on the cert and what to do instead.

Decommission checklist for a hostname

Use a quick, practical checklist:

- Confirm new canonical and redirects are live (HTTP and HTTPS).
- If HSTS was set, serve redirects over HTTPS until user caches expire; only then consider dropping TLS.
- Crawl the old hostname to ensure all paths 301 cleanly to the new target (no chains).
- Update sitemaps and remove legacy URL references in paid ads, emails, and internal links.
- Reissue the UCC without the SAN and deploy everywhere.
- Monitor 404/410s and traffic - only after stabilization, update DNS to remove the old A/AAAA/CNAME.

Certificates touch every edge. Treat SAN edits as a change event with a backout plan. Keep the previous certificate and keys stored securely and ready to redeploy if something goes sideways. Have your server config diffs reviewed before the window starts, and set explicit communication in Slack/Teams so people aren’t guessing what’s live.

Lower DNS TTLs 24–48 hours prior if you plan validation or endpoint changes that rely on DNS. If your CA uses DNS DCV and your DNS provider is slow, stagger validations. Bundle the reissue only after all DCV checks pass. The fewer moving parts during the window, the better.

Define success metrics: no TLS handshake errors, no spike in 4xx/5xx, SSL Labs A grade, and clean redirect behavior. Define rollback triggers: persistent chain errors, client compatibility complaints, or failures on critical paths (checkout, login, lead forms). If a trigger hits, revert certs and configs quickly, then debug out of band.

Run SSL Labs against each hostname to confirm the certificate chain, supported protocols, and SNI behavior. Look for accidental legacy-only ciphers or disabled OCSP stapling if your compliance requires it. Check Certificate Transparency logs to verify the new SANs are properly logged and no surprises leaked.

From an SEO and analytics view, test canonical tags, redirects, and mixed-content warnings. If you added a secure hostname for a landing page, validate that your analytics and conversion pixels fire correctly after the TLS swap. Mixed content can silently kill tracking if an old HTTP asset slips through.

Set up monitors: endpoint probes for TLS expiry, uptime checks per hostname, and alerts for certificate mismatch. Add a certificate-expiry dashboard to your ops view so this doesn’t become a quarterly fire drill.

Cost sneaks up with SANs. CAs often price per additional SAN beyond a base pack. If you’re constantly adding domains, a wildcard or ACME-driven setup might be cheaper in ops hours and vendor fees. That said, if you must cover multiple different apex domains, a SAN cert is cleaner than juggling many separate certs.

Consider where TLS terminates. If you’re on a CDN like Cloudflare, Fastly, or Akamai, they can manage certificates for you - sometimes at no extra cost for SANs, sometimes with strict limits. AWS ACM is free within AWS for ELB/CloudFront and offers easy SAN management via API. Centralizing termination can simplify rollouts and reduce the chance an edge cluster is left behind.

Compatibility matters if you serve very old clients or embedded systems. SNI is standard now, but if you still support legacy devices, a single IP per cert might be necessary. Test your audience rather than guessing; your analytics should tell you if old clients hit your endpoints.

If you’re a founder or marketing leader, SSL isn’t your core job - but it kills campaigns when it breaks. This is the space an operator fills: one senior person who handles the stack end to end - domains, SSL, CDNs, landing pages, analytics - while your team focuses on offers and channels. At Anton Chisliuk · AI Marketing Ops, we run that model: build systems, then scale traffic. Proof, not theater - e.g., for Cleverence (B2B SaaS) we took organic from zero to 80K visits/month and 2K inbound leads/month while the site and infrastructure stayed stable. If you want the full background on the operator model and how it replaces agency layers, read the short company overview on our About page.

Even if you keep SSL in-house, borrow the mindset: treat certs as part of the growth system. When you launch a campaign, a subdomain and its cert are dependencies like budgets and creatives. Put them on the checklist and the calendar.

No lock-in, no agency tax - just the work shipped and verified. Whether you DIY or bring in help, get the certificate playbook documented so new teammates don’t relearn it under pressure.

Say you run example.com on a UCC that already secures www.example.com and app.example.com. Your team is adding eu.example.com for a regional launch and blog.example.co for a partner-hosted content hub. You also want to retire stage.example.com. Here’s the sane flow:

- Prep DCV: DNS TXT for eu.example.com and blog.example.co. Lower TTLs to 300 seconds the day before.
- Buy two SAN slots if your CA requires it. Generate a new CSR if you rotate keys annually; otherwise reuse the existing key for less friction.
- Reissue request: add both new SANs, complete DNS DCV, wait for issuance.

- Stage: install the new cert on a canary server and verify both new hostnames. Confirm the chain and SNI behavior on staging.
- Production: deploy the new cert to your load balancer/CDN and origin servers. Update IIS bindings or Nginx paths, reload gracefully, verify with SSL Labs per hostname.
- Decommission: ensure stage.example.com 301s to www.example.com over HTTPS, keep it on the cert for one week to drain caches, then reissue without stage.example.com and redeploy.

Throughout, you track a rollback artifact (previous cert and configs), monitor errors, and document the change. No heroics required, just a practiced motion.

Don’t forget intermediates. A missing intermediate CA breaks some clients even if your browser looks fine. Always deploy the full chain bundle your CA provides. Test with more than your own laptop.

Don’t rely on only one endpoint update. If you terminate at a CDN and also at an origin for private links, both need the new certificate. Same for multi-region load balancers. Create a target list and check them off.

Don’t remove SANs before redirects are in place. If you drop TLS on a hostname with HSTS set, users can’t reach the redirect. Serve HTTPS long enough to hand users to the new canonical, then retire.

Make a simple RACI: marketing requests new hostnames, ops owns DCV and deployment, security approves key management and CA vendor, and product signs off on timing. A two-sentence form beats a Slack thread when you need an audit trail.

For frequent edits, template everything. A request template should include the exact hostnames, preferred DCV method, desired go-live date, TTL changes, whether a key rotation is requested, and which environments (prod, staging) need coverage. That clarity cuts days off the cycle.

If you serve multiple brands, consider separating certificates by business line. That reduces blast radius and politics - no one brand blocks another’s launch because a shared UCC is stuck in review.

Use secrets managers for private keys and automate CSR generation with reproducible parameters. In CI/CD, keep environment variables for cert paths and use rolling reloads. Add a preflight job that checks expiry dates and SAN mismatches before each deploy.

For ACME, wire DNS validation with your DNS provider’s API. Many DNS vendors support API tokens for automatic TXT record creation. This makes adding SANs as simple as merging a pull request that updates a domains list in code.

Finally, alert before panic. Set expiry alerts at 45, 30, 14, and 7 days. Tag owners in the alert. If you want a higher bar, set an SLO: no certificate reaches 14 days to expiry without a scheduled renewal/reissue task on the calendar.

Adding or removing SANs from a UCC isn’t glamorous, but it’s straight-line work when you treat it like any other production change: inventory, DCV plan, reissue, staged deploy, validation, and clear rollback. Do the redirects and HSTS dance properly, and you’ll protect both conversions and your team’s sanity.

If you want a second set of eyes on your SSL and launch ops, book a quick, no-fluff assessment - we look at your stack, map risk, and hand you the plan. Start with a free Growth Audit. Article by Anton Chisliuk.

- Will reissuing my UCC to add SANs cause downtime?

No, not if you plan it. You can stage the new cert, then rotate live with a graceful reload on your servers or load balancers. Keep the old cert handy for rollback until validation passes.

- Do I need a new CSR and private key when I add SANs?

Not always. Most CAs let you reissue using the existing key. If you want a key rotation for security hygiene, generate a new CSR and distribute the new private key to all endpoints as part of the rollout.

- Which DCV method is best for multiple new SANs?

DNS TXT validation is the most reliable at scale. It avoids issues with CDNs, reverse proxies, and vendor-hosted origins where you don’t control the web root. Use HTTP DCV only when you control the serving path.

- Can I mix wildcard and specific SANs in one certificate?

Yes, many CAs allow mixing a wildcard like *.example.com with specific SANs (e.g., login.example.com, example.net). Check your vendor’s limits and pricing for wildcards inside SANs.

- How many SANs can I add to a UCC?

It varies by CA and product tier. Common limits range from 25 to 100+ SANs. Confirm your current cap and per-SAN pricing before you plan expansions to avoid mid-change surprises.

- Do EV/OV UCCs support SAN edits the same way DV does?

Functionally yes, but EV/OV may add organization checks and slower issuance time. Plan longer windows and ensure your legal/company details match what the CA has on file to prevent delays.

- What happens to expiry when I reissue?

Reissue typically keeps the original expiry date. Renewal extends it. Some vendors blur the line with “renewal reissue” flows; read your CA’s docs to avoid unexpected short terms.

- Can I use Let’s Encrypt for multi-domain SAN certificates?

Yes. Let’s Encrypt supports SAN certificates via ACME. You’ll manage 90-day validity and automation, usually via DNS-01 or HTTP-01 validation. For EV/OV or long terms, use a commercial CA.

- Can I secure an IP address as a SAN?

Most public CAs do not issue certificates for bare IP addresses. Use DNS hostnames. For internal/private services, your internal PKI can issue IP SANs, but that won’t be trusted by public browsers.