SSL certificates now expire much sooner: what changes and what to do

It is Monday morning and residents trying to renew a permit online get a full-page browser warning: "Your connection is not private." Nothing was deployed over the weekend. The certificate simply expired, because the renewal reminder went to someone who left months ago. The same thing happens to university application portals and nonprofit donation pages every week. Over the next three years it will happen far more often to anyone who still renews by hand, because the maximum lifetime of a public certificate is being cut from about thirteen months to 47 days.

What is changing, and when

The CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for public certificates, approved a phased reduction in 2025. It applies to every publicly trusted SSL/TLS certificate, whichever authority you buy from:

The third column matters as much as the second. Before issuing a certificate, the authority checks that you control the domain, through a DNS record or a file on the web server. By 2029 that proof is reusable for only ten days, so almost every renewal needs a fresh check. A process that relies on someone clicking an approval email will not keep up.

Certificates already issued keep their original expiry date, and private certificates used only inside your own network are outside these rules.

Why the rules are changing

A shorter lifetime limits the damage when a private key leaks or a certificate is issued by mistake, because the bad certificate stops working sooner. It also pushes everyone toward automation.

Check where you stand today

Start with an inventory. Most organizations find more certificates than expected: staging sites, campaign domains, the CDN, and vendor endpoints. For each public hostname, check the issuer and expiry date:

echo | openssl s_client -servername www.example.edu -connect www.example.edu:443 2>/dev/null | openssl x509 -noout -issuer -enddate

• Issued by Amazon: the certificate most likely comes from AWS Certificate Manager (ACM), which renews public certificates automatically as long as its DNS validation record stays in place. Check that the record has not been deleted during a DNS clean-up.
• Issued by Let's Encrypt or another ACME authority: renewal is automated by a client on the server. Confirm the client runs on a schedule and that its last renewal succeeded.
• Bought from a commercial authority and installed by hand: this group needs a plan. At 47 days, that means a manual renewal about every six weeks per hostname.

Also note any certificate copied by hand onto an appliance, a mobile app, a partner's system, or an email gateway. Those copies are the ones that expire unnoticed.

What to do about it

1. Automate every public certificate. Use the issuing service built into your platform where one exists (ACM for AWS load balancers and CloudFront, your CDN's managed certificates) or an ACME client on the server. The goal is that no human renews a public certificate.
2. Prefer DNS validation. A DNS record that stays in place lets the authority re-check your domain on every renewal.
3. Monitor expiry independently. Automation can fail quietly, for example when a validation record is removed. Alert when any certificate is within 14 days of expiry, and route the alert to a team, not one person.
4. Retire certificate pinning. Apps or partners that pin a specific certificate break on every renewal. Remove pinning.
5. Retest after every move. When a hostname moves to a new CDN or load balancer, confirm the new endpoint renews on its own.

What this means for WordPress, Drupal, and Cascade sites

The CMS itself rarely holds the certificate. It sits on the load balancer, the CDN, or the web server in front of the CMS, so this is a hosting task rather than a content task. For Cascade sites, the published site's certificate lives on the publish destination or its CDN. Certificates for the Cascade editing interface are managed by Hannon Hill.

Government agencies: an expired certificate takes the site offline

Drupal powers roughly a quarter of government websites, and agencies face a stricter version of this problem. Every new .gov domain registered since September 2020 is on the browsers' HTTPS preload list, and federal agencies are required to enforce HTTPS the same way. On a preloaded domain, an expired certificate is not a warning visitors can click past: browsers refuse to load the site at all. For an agency, that means residents cannot reach services until the certificate is replaced. Agencies with many department and program subdomains should treat automated renewal and expiry monitoring as an availability requirement.

How eWay handles certificates

On environments eWay manages, TLS 1.2 or higher is enforced and all HTTP traffic is redirected to HTTPS. On AWS, certificates are issued and renewed automatically by AWS Certificate Manager. Other environments renew automatically through an ACME client or the hosting platform's managed certificates, for example on Azure. Either way, certificate expiry is one of the signals eWay monitors around the clock, so a renewal that fails raises an alert to the on-call engineer rather than a browser warning for your visitors. If any of your certificates are still renewed by hand, eWay can help move them to automatic renewal before the 2027 deadline.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times). An expired certificate on a production site is a P1.
• The affected hostnames
• The browser error or a screenshot of it
• Whether the certificate was installed by your team, a vendor, or eWay

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. Related reading: SSL and HTTPS for WordPress and Drupal, SSL certificates and domain management for Cascade sites, and keeping servers patched.