How to Prepare for 47-Day SSL Certificates

Forty-seven day certificates are not just "more renewals." They force teams to fix ownership, validation, deployment, and monitoring.

By March 15, 2029, public TLS certificates will max out at 47 days, and domain validation reuse will shrink to 10 days. Any process that still depends on personal reminders, manual DNS work, or ad hoc deployment will become fragile fast.

What breaks first

Most teams do not fail because issuing the certificate is impossible. They fail because one of the surrounding steps is weak:

• nobody clearly owns the certificate
• validation still depends on manual DNS or email
• issuance is automated, but deployment is not
• the live endpoint is never checked after renewal
• one legacy system still uses a fully manual process

That is why preparation should focus on the full lifecycle, not just the CA portal.

A practical preparation plan

1. Build an inventory

For every public certificate, document:

• hostname or service
• deployment location
• certificate type: DV, OV, or EV
• renewal method
• deployment method
• owner

If you cannot answer those questions quickly, you are not ready for short lifetimes.

2. Classify every renewal path

Use three buckets:

• fully automated
• partially automated
• fully manual

The goal is to remove as many manual paths as possible before 2029.

3. Automate validation

This is where many teams will struggle. When domain validation reuse drops to 10 days, slow human approval chains become dangerous.

In most environments, that means:

• prefer DNS-based automation where possible
• standardize on ACME where supported
• keep DNS ownership clean and documented
• reduce one-off certificate requests outside standard workflows

4. Automate deployment, not just issuance

"We already renew automatically" is not enough if the new certificate never reaches the live edge.

You want a full loop:

1. request or renew
2. validate
3. issue
4. deploy
5. reload safely
6. verify the live endpoint

If the process stops at step 3, it is not fully automated.

5. Add independent monitoring

Even good automation breaks. DNS records change, permissions expire, webhooks fail, and legacy systems get forgotten.

Monitoring should tell you two things:

• which certificates are approaching expiry
• whether the public endpoint is serving the expected certificate

That second check is the one teams often miss.

6. Handle awkward systems early

The real risk is usually not the clean modern stack. It is the old load balancer, vendor panel, customer-managed environment, or appliance that nobody wants to touch.

List those systems now and give them a migration or exception plan.

A short readiness checklist

Before the 47-day era arrives, make sure you can say yes to these:

• every public certificate has an owner
• renewal paths are documented
• validation is automated where possible
• deployment is automated for critical systems
• alerts fire before expiry
• live endpoints are verified after renewal
• legacy exceptions are known and tracked

Use 200 days as a rehearsal

Do not wait for 2029. The 200-day and 100-day steps are rehearsal phases. They give you time to clean up bad habits before certificate management turns into a constant source of incidents.