Managing SSL Across Thousands of Redirect Domains

Managing SSL certificates for a handful of domains is straightforward. Managing SSL certificates for thousands of redirect domains is an entirely different operational challenge. As Let's Encrypt prepares to shorten certificate lifetimes to 45 days, enterprise teams managing large domain portfolios face a multiplying workload — more renewals, more failure points, and more risk of expired certificates taking down business-critical redirects. This guide breaks down the operational reality of SSL at enterprise domain scale and shows how modern redirect infrastructure eliminates the manual certificate grind.

The Enterprise Domain Profile#

Enterprise organizations rarely own just one domain. Marketing teams register campaign-specific domains for every launch. Brand protection teams acquire typo variants, ccTLDs, and defensive registrations across dozens of TLDs. Corporate development adds domains through acquisitions, each with its own redirect requirements.

A mid-size SaaS company might manage 300–500 domains. A large e-commerce operation could have 2,000+. Domain investors and portfolio managers routinely handle 10,000 to 300,000 domains — each one needing HTTPS to function as a redirect endpoint.

Every domain in these portfolios needs SSL. Without it, visitors see browser warnings. Redirects break. Trust erodes. For domains that exist purely to redirect traffic — campaign URLs, acquired brand domains, typo variants — an expired certificate means the redirect doesn't work at all. Modern browsers block the connection before the redirect even fires.

The cost of a single expired certificate varies wildly. A campaign domain going dark during a product launch can cost tens of thousands in wasted ad spend. An acquired brand domain losing HTTPS means lost traffic during the critical post-acquisition window. At scale, these failures compound — and manual certificate management simply doesn't scale with the portfolio.

Certificate Strategy at Scale: Wildcard vs SAN vs Per-Domain#

When you manage SSL for thousands of domains, certificate strategy becomes an architectural decision. The three primary approaches each carry distinct tradeoffs that compound at scale.

Wildcard certificates cover all subdomains under a single domain. They reduce the total number of certificates you need and simplify renewal. But wildcards have critical limitations for redirect portfolios. A wildcard for *.brand.com doesn't cover brand.co.uk or brand.de. For redirect domains that span multiple apex domains — which most enterprise portfolios do — wildcards create more gaps than they fill. They also spread risk: compromise a wildcard private key and every subdomain is exposed.

Multi-domain SAN certificates bundle multiple domains into a single certificate. This approach reduces certificate count and centralizes renewal. But SAN certificates hit practical limits quickly. Let's Encrypt caps SAN certificates at 100 domains per certificate. For a 2,000-domain portfolio, you would need at minimum 20 separate SAN certificates, each with its own renewal schedule, CSR process, and private key management. Add or remove a domain and the entire certificate needs reissuing — a cascade of operational overhead.

Per-domain certificates provision one certificate per domain. This is the default approach for most platforms. It means each domain operates independently — no shared keys, no shared risk. But manual per-domain management at enterprise scale creates its own nightmare: thousands of renewal dates to track, thousands of private keys to secure, thousands of ACME challenges to complete. Spreadsheets don't scale here. Neither do calendar reminders.

The right strategy depends on the architecture handling the certificates. A redirect platform that manages SSL per-hostname automatically shifts this tradeoff: per-domain certificates become operationally invisible because the platform handles issuance, renewal, and installation without human intervention.

The Rate Limit Problem#

Let's Encrypt rate limits aren't a footnote — they are the primary constraint that determines whether your SSL strategy works at scale.

Let's Encrypt enforces several rate limits, but the most impactful for enterprise redirect portfolios is the Certificates per Registered Domain limit: 50 certificates per registered domain per week. If you own brand.com and need certificates for campaign1.brand.com, campaign2.brand.com, and 48 more subdomains, you can do that in a week. Need 200? You will hit the limit.

For multi-domain portfolios, the Duplicate Certificate limit adds another constraint: you cannot issue more than 5 identical certificates per week for the same set of hostnames. If your SAN certificate strategy requires reissuing certificates with overlapping domain sets, this limit kicks in fast.

The New Orders limit caps you at 300 new certificate orders per account per 3-hour window. At 2,000 domains with per-domain certificates, initial provisioning requires staging the rollout across multiple days even under ideal conditions.

These aren't theoretical bottlenecks. Teams migrating large portfolios onto automated SSL infrastructure hit these limits during the initial provisioning phase. The solution requires building rate-limit awareness into your certificate automation — queuing, retrying with exponential backoff, and provisioning across multiple Let's Encrypt accounts when necessary. Manual workflows simply don't have the state tracking to handle this.

NS Delegation vs CNAME: Why DNS Architecture Changes SSL Management#

How you point DNS for your redirect domains determines the entire SSL automation architecture.

CNAME at apex is the standard setup: point each domain to the platform and everything downstream is handled automatically. This works well for portfolios where you manually add domains one at a time. SSL is auto-provisioned when DNS is verified. The problem at scale is the setup: each domain requires individual DNS configuration. For 5,000 domains, that is 5,000 DNS changes to make and verify.

NS delegation shifts the equation entirely. Instead of CNAME records per domain, you point the authoritative nameservers for entire domain portfolios to the redirect platform. One change at the registrar level covers every domain delegated to those nameservers. The platform then handles DNS resolution, redirect configuration, and SSL provisioning for every delegated domain.

This architecture fundamentally changes SSL management because the platform now owns the entire DNS + SSL lifecycle. Auto-provisioning happens domain-by-domain, but the platform controls the verification flow end-to-end. No per-domain DNS configuration required from your team. No waiting for DNS propagation across external providers.

Enterprise-scale operators — particularly domain investors with hundreds of thousands of domains — use NS delegation because the operational overhead of per-domain CNAME setup is simply prohibitive. Enterprise redirect infrastructure built for this scale handles the entire DNS + SSL lifecycle automatically.

How Redirect Platforms Auto-Provision SSL per Hostname#

Understanding the automation pipeline helps set realistic expectations for what enterprise SSL management should look like. The flow is straightforward but needs to handle failures gracefully at scale.

Step 1 — DNS verification: When a hostname is added, the platform checks DNS propagation. For NS-delegated domains, verification is near-instant because the platform controls the authoritative DNS. For CNAME-configured domains, the platform polls until the CNAME resolves correctly.

Step 2 — Certificate issuance: Once DNS is verified, the platform initiates an ACME order with Let's Encrypt. The challenge type depends on setup — HTTP-01 for standard configurations, DNS-01 for wildcard or NS-delegated domains. Rate limits are tracked and queued automatically.

Step 3 — Installation: The issued certificate is installed at the edge. For a globally distributed redirect platform, this means pushing the certificate to all edge locations. Certificate installation at the edge is measured in seconds.

Step 4 — Renewal: The platform monitors certificate expiry dates. Standard renewal triggers at 30 days before expiry — well within the 45-day certificate lifetime coming from Let's Encrypt. If renewal fails, the platform retries with backoff and escalates if the certificate approaches expiry.

The key operational difference from manual management: the platform tracks each certificate's state across its entire lifecycle — issuance, installation, renewal, and expiry. There is no spreadsheet. No person gets paged at 2 AM because a certificate renewal failed. The platform handles retries and escalates only when intervention is genuinely needed.

The Monitoring Layer: Global Health Checks#

SSL automation is only as good as its monitoring. Certificates can be auto-provisioned, auto-renewed, and auto-installed — and still fail silently if nobody is watching.

Enterprise redirect platforms add a monitoring layer that manual certificate management simply cannot provide: global health checks from multiple edge locations. Each domain's HTTPS endpoint is probed at regular intervals from geographically distributed checkpoints. If a certificate expires or fails to renew, the monitoring layer detects it — often before any visitor encounters a browser warning.

For a team managing thousands of redirect domains, this monitoring layer replaces the impossible task of manually checking certificate status across the portfolio. Instead of hoping renewal scripts worked, the team gets proactive alerts when something goes wrong. Instead of discovering expired certificates through user complaints, the platform catches failures during automated health checks.

The monitoring layer also validates beyond just certificate status. It checks SSL configuration — minimum TLS version, cipher suites, HSTS headers — ensuring every domain meets security standards across the entire portfolio. For enterprise teams with compliance requirements, this automated validation is essential.

Case Study: 3,000-Domain Portfolio Migration#

Consider a domain portfolio manager handling approximately 3,000 domains across multiple TLDs — brand domains, campaign URLs, acquired properties, and defensive registrations. Prior to automation, SSL management meant:

• •
  Tracking certificate expiry dates in a shared spreadsheet
• •
  Manually generating CSRs and completing ACME challenges for each renewal
• •
  Coordinating certificate installation across multiple servers and CDNs
• •
  Discovering expired certificates when users reported broken redirects
• •
  Spending approximately 15–20 engineering hours per week on certificate operations

The migration to automated SSL infrastructure involved three phases:

Phase 1 — DNS consolidation: All 3,000 domains were pointed to the redirect platform via NS delegation. This was the largest one-time effort, completed over two weeks with batch processing.

Phase 2 — Initial provisioning: The platform began auto-provisioning SSL certificates. Rate limits meant the initial rollout took approximately 5 days for full coverage. During this period, existing certificates remained active — no downtime.

Phase 3 — Steady state: Once all domains had auto-provisioned certificates, the operational burden dropped to near zero. Certificate renewals happen automatically. The monitoring layer catches exceptions. Engineering time spent on SSL dropped from 15–20 hours per week to under 1 hour per month — and that hour is spent reviewing automated reports, not manually renewing certificates.

The most telling metric: zero expired certificates in the 18 months since migration. Prior to automation, the portfolio averaged 8–12 expired certificates per month.

Conclusion#

The 45-day certificate era is coming, but the enterprises that will feel it are the ones still managing SSL manually. For teams running redirect infrastructure at scale — thousands of domains, dozens of TLDs, multiple edge locations — manual certificate management has already been unsustainable. Shorter certificate lifetimes just make the math undeniable.

Modern redirect platforms handle the entire SSL lifecycle: DNS verification, certificate issuance, edge installation, auto-renewal, and global health monitoring. The operational model shifts from "track certificates in a spreadsheet" to "review automated reports once a month."

Your domain portfolio should not own your engineering calendar. Automate SSL at scale and let your team focus on what actually drives the business forward.

Start free with RedirHub to see how automated SSL provisioning works across your domain portfolio — no credit card required. Our enterprise plan adds dedicated infrastructure, NS delegation, and 100% uptime SLA for teams managing SSL at the largest scale.