Skip to content

← Blog

Wildcard Renewal Timeline: 30–45 Days to Start for Sysadmins

By Nick Phillips, Founder

Wildcard Renewal Timeline: 30–45 Days to Start for Sysadmins

Decorative SSL renewal timeline title card

A wildcard renewal can finish in minutes when DNS API automation handles the validation step, but it commonly stretches into hours or days when a human has to touch DNS records or click through a manual issuance flow. The single gating factor to watch is DNS: if your validation is automated, act on schedule; if it’s manual, start early and have a fallback cert ready in case something stalls.

TL;DR:

  • DNS validation automation can complete wildcard renewals in seconds, but manual DNS updates may require hours or days, risking delays if not started early.
  • The renewal process involves four stages: notification, validation, issuance, and deployment, with deployment often extending the timeline if manual steps are involved.
  • Troubleshooting common failures requires checking DNS records, CAA restrictions, DNS API credentials, and performing dry-run tests to prevent unexpected outages.
  • Automating DNS challenges, validating the entire process beforehand, and keeping an inventory of certificate deployments reduce the risk of service disruption.
  • Regular post-deployment checks on all endpoints ensure the renewed certificate is correctly serving everywhere, avoiding silent outages.
Otterwatch
Catch Certificate Expiry Before It Hurts
Otterwatch watches your SSL certificates and quietly checks that your sites stay up, with plain alerts instead of dashboard noise.
See how Otterwatch works

Table of Contents

Why wildcard renewals behave differently from single-host certificates

A wildcard cert covers every subdomain under one name, which sounds convenient until renewal day, because most certificate authorities require DNS-01 validation for wildcards rather than the simpler HTTP-01 method used for single hosts. That means someone (or something) has to create a specific DNS TXT record before the CA will reissue the cert.

A few things drive how long that actually takes:

  • DNS-01 validation can be scripted through your DNS provider’s API, or it can require someone logging in and adding a record by hand.
  • CA notification windows and validity periods set when you first hear about an upcoming renewal, not when the work actually happens.
  • Deployment to your servers, load balancers, or CDN can be automatic on some platforms and a manual copy-paste job on others.

The parts you can automate tend to be fast. The parts that still require a person are where timelines slip.

How wildcard renewal works: the step-by-step flow and where time is spent

Every wildcard renewal moves through four stages, and knowing which one you’re stuck in makes troubleshooting a lot faster.

  1. Notification. Your CA or platform typically flags the renewal well ahead of expiry. AWS Certificate Manager attempts renewal starting 45 days before expiration for DNS-validated certificates, which is a common reference point in certificate renewal processes.
  2. Validation. The CA needs proof you control the domain, usually a DNS-01 TXT record. With API automation this can complete in seconds. Done by hand, you’re waiting on someone to log in, plus however long your DNS provider takes to propagate the change.
  3. Issuance. Once validation is visible, the CA issues the new certificate, usually within minutes to a few hours.
  4. Deployment. The new cert has to actually reach your servers, load balancers, or CDN edge nodes. This step is where caches and stale configs quietly extend the timeline well past when the cert was technically issued.

Pro Tip: Treat “renewal initiated” as a prompt to check issuance and deployment separately, never as proof the new cert is already live.

Typical timelines by validation and deployment method

The method you use for DNS validation, and how your deployment is wired up, sets the real-world range you should plan around.

  • DNS-01 with API automation: validation often completes in seconds to minutes, issuance follows in minutes to an hour, and deployment speed depends entirely on how automated your rollout is.
  • DNS-01 done manually: expect hours to days, since you’re waiting on a person to make the change plus whatever TTL and propagation delay your DNS provider adds.
  • HTTP-01: faster when it’s available, but it generally can’t validate a wildcard because it proves control of one specific path on one specific host, not an entire subdomain space.
  • Managed CA services: ACM’s managed renewal runs asynchronously, so issuance can be quick while deployment to attached resources takes several hours to fully catch up.

Automated DNS-01 challenges typically resolve in seconds to minutes once your provider’s API is wired in, which is the main reason Let’s Encrypt’s community guidance steers people away from manual DNS challenges for anything meant to renew unattended.

Common failure modes and troubleshooting checklist

Most “the renewal is stuck” incidents trace back to one of a small set of causes, and checking them in order saves time.

  • DNS record errors: wrong record name or type, a typo in the TXT value, or a delegation mismatch between your registrar and DNS host.
  • CAA restrictions: a CAA record that doesn’t authorize your chosen CA will block issuance outright.
  • Expired or misconfigured DNS API credentials: a common cause of automated renewals failing silently, according to AWS’s troubleshooting guidance.
  • Imported or provider-mismatched certificates: certs brought in from elsewhere often fall outside a platform’s automatic renewal scope and need manual handling.

When something goes wrong, work through it in this order: check the CA’s validation status first, then run dig or host against the challenge record to confirm it’s actually visible, then check the certificate’s status in your CA console, and finally run a dry-run renewal to isolate whether the problem is DNS or the client itself.

Pro Tip: A dry-run (certbot renew --dry-run or an ACME staging endpoint) is the cheapest way to catch a broken credential before it costs you a production outage.

Practical reminders, automation, and a schedule that avoids surprises

A little structure around your renewal calendar turns a stressful deadline into a routine task.

  1. Set a first reminder 30 to 45 days before expiry, with follow-ups at 14 and 7 days if any part of the process still requires manual DNS work.
  2. Use your DNS provider’s API, or a delegated CNAME setup, so DNS-01 challenges can run without anyone touching a console.
  3. Validate the whole pipeline with a dry-run well before the real deadline. Certbot practitioners specifically recommend relying on saved renewal configuration files and running certbot renew --dry-run rather than overriding options ad hoc.
  4. Keep an inventory of every place the wildcard cert is installed, along with a documented rollback plan (a temporary single-host cert works fine as a stopgap) so an unexpected failure doesn’t turn into an outage while you scramble.

A good runbook, drawn from ACM’s own troubleshooting notes, looks something like this: dry-run at 60 days out, resolve any manual DNS steps and confirm with dig, run the production renewal at 30 days, then automate a post-deploy check that alerts you if any endpoint is still serving the old cert.

Confirming the renewed certificate is actually serving everywhere

Issuance is not the finish line. The cert has to show up correctly on every edge point that terminates TLS for your domains.

  • Run openssl s_client -connect host:443 -servername yourdomain.com to check the live cert and chain, and pair it with curl -v for a quick sanity check from the command line.
  • Check certificate transparency logs and your CA console to confirm the new cert was actually issued and not just requested.
  • Verify every load balancer, CDN edge, and cache layer separately, since these are notorious for holding onto the old cert well after the origin has been updated.
  • Automate a recurring post-deploy check that flags any endpoint still presenting the previous certificate.

Our guide to avoiding SSL expiration warnings walks through this verification step in more detail if you want a repeatable checklist.

What sysadmins consistently underestimate about renewal risk

What sysadmins consistently underestimate about renewal risk — overview diagram

The part of wildcard renewal that trips people up isn’t usually the certificate authority. It’s the gap between “the new cert was issued” and “every service is now presenting it,” and that gap is exactly where outages quietly happen. Teams that automate DNS-01 and skip the dry-run step still get burned, because a credential can expire or a CAA record can change without anyone noticing until renewal day.

Frameworks like NIST SP 800-53 point toward the same conclusion from a different angle: keep an inventory, minimize the scope of what a single wildcard covers where you can, and treat certificate management as an ongoing control rather than a once-a-year fire drill. A calm, boring reminder well before expiry beats a frantic one on the day of.

— Nick Phillips

Otterwatch: a calmer way to keep renewal timelines from ambushing you

Otterwatch watches your certificates and quietly checks that your sites are still reachable, sending a plain heads up well before anything expires instead of burying you in dashboards. For teams juggling wildcard renewals across a handful of domains, that early warning window matters more than any alarm after the fact.

Otterwatch

Otterwatch is free for up to five domains with no credit card required, and the Pro plan at a monthly fee provides deeper monitoring and change-detection for anyone managing more. If you just want to confirm a freshly renewed wildcard cert is actually serving correctly right now, run it through the free SSL certificate checker and see for yourself.

Sources

FAQ

How long does a wildcard certificate last?

Validity periods depend on the issuing CA and your organization’s policy rather than a single fixed rule, so the safest approach is to check your CA console for the exact expiry date rather than assume a default. Regardless of the exact period, renewal planning should start well before that date, not on it.

What happens if a wildcard certificate expires?

Every subdomain covered by that certificate will start showing browser security warnings or failing TLS handshakes entirely, which can take down multiple services at once. The immediate fix is to deploy a temporary certificate, even a single-host one, on the most critical subdomains while you resolve the wildcard renewal.

Why can’t I use HTTP-01 validation for a wildcard certificate?

HTTP-01 proves you control one specific file path on one specific hostname, which doesn’t establish control over an entire subdomain space. That’s why most CAs require DNS-01 validation for wildcard certificates, since it proves control at the DNS level instead.

What usually causes a wildcard renewal to fail unexpectedly?

The most common causes are expired DNS API credentials, DNS records that were changed or removed, and CAA restrictions that block the CA from issuing, according to AWS’s troubleshooting guidance. Running a dry-run renewal ahead of the real deadline catches most of these before they become an outage.

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →