AETERNAE AI RESEARCH LLC INDEPENDENT RESEARCH
ÆAETERNAERESEARCH
Sign inRequest access
← Malware catalog

Attributed metadata history

REPORTPUBLIC METADATA

Decreasing Certificate Lifetimes to 45 Days

Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028. This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient. We are also reducing the authorization reuse period, which is the length of time after validating domain control that we allow certificates to be issued for that domain. It is currently 30 days, which will be reduced to 7 hours by 2028. Timeline of Changes To minimize disruption, Let’s Encrypt will roll this change out in multiple stages. We will use ACME Profiles to allow you control over when these changes take effect. They are configured in your ACME client. For more information, see our blog post announcing them. Changes will be deployed to our staging environment approximately one month before the production dates below. May 13, 2026: Let’s Encrypt will switch our tlsserver ACME profile to issue 45-day certificates. This profile is opt-in and can be used by early adopters and for testing. February 10, 2027: Let’s Encrypt will switch our default classic ACME profile to issuing 64-day certificates with a 10-day authorization reuse period. This will affect all users who have not opted into the tlsserver or shortlived (6-day) profiles. February 16, 2028: We will further update the classic profile to issue 45-day certificates with a 7 hour authorization reuse period. These dates are when the change takes effect for new certificates, so Let’s Encrypt users will see the reduced certificate validity period at their next renewal after these dates. Action Required Most users of Let’s Encrypt who automatically issue certificates will not have to make any changes. However, you should verify that your automation is compatible with certificates that have shorter validity periods. To ensure your ACME client renews on time, we recommend using ACME Renewal Information (ARI). ARI is a feature we’ve introduced to help clients know when they need to renew their certificates. Consult your ACME client’s documentation on how to enable ARI, as it differs from client to client. If you are a client developer, check out this integration guide. If your client doesn’t support ARI yet, ensure it runs on a schedule that is compatible with 45-day certificates. For example, renewing at a hardcoded interval of 60 days will no longer be sufficient. Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime. Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes. We also recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren’t renewed when expected. There are many available options, some of which are documented on our Monitoring Service Options page. Making Automation Easier with a new DNS Challenge Type For many of our users, the hardest part of automatically issuing certificates is proving domain control. Reducing certificate lifetimes and the authorization reuse period will make users need to demonstrate control more often. All validation methods today require that the ACME client have live access to your infrastructure, either to serve the correct HTTP-01 token, perform the right TLS-ALPN-01 handshake, or update the right DNS-01 TXT record. For a long time, people have wanted a way to run an ACME client without granting it access to these sensitive systems. These challenges are why we a

Reference details

Source category
research-report
First reported
Dec 02, 2025 00:00 UTC
Last reported
Dec 02, 2025 00:00 UTC
Catalog updated
Oct 13, 2026 00:10 UTC
Record ID
7f93c5a6fbb194f66ef4c2f873b19b69db655a936308ef0815d3ae55d12214ca

Published indicators

Network indicators are visibly defanged. This page does not make them clickable or send them to another service.

No validated file hashes or network indicators are stored for this record.

Source observations

intelligence_src_823f7b237762257237

Source-provided label
Publisher RSS metadata
Evidence class
mentioned in report
Confidence
Not reported
Observed
Dec 02, 2025 00:00 UTC
Retrieved
Oct 13, 2026 00:10 UTC

This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.

Feed collection status

Sources represented on this page. Publication and observation dates describe the content; successful batch dates describe local collection. A recent batch does not certify complete coverage or current provider availability.

1 sources: 0 stale, 0 needing attention, 0 paused, 0 unverified.

Review source update dates and status
  • intelligence_src_823f7b237762257237Recent successful batchLast successful batch: Last attempt:

Stale means older than twice the recorded collection interval, with a minimum of one hour; without an interval, the threshold is 24 hours. Cached content remains available while a feed is stale, paused, or unverified.