# TLS certificate lifetimes: the 200, 100 and 47 day limits > Publicly trusted TLS certificates are getting shorter. This page lists the CA/Browser Forum schedule, the Let's Encrypt changes and the alert thresholds that fit each lifetime. Source: https://sslmonitor.com/certificate-lifetimes/ ## The short answer A publicly trusted TLS certificate issued on or after March 15, 2026 can be valid for at most 200 days. The limit drops to 100 days for certificates issued on or after March 15, 2027, and to 47 days on or after March 15, 2029. Certificates issued before March 15, 2026 could be valid for up to 398 days. These limits come from section 6.3.2 of the [CA/Browser Forum Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md), the rules every publicly trusted certificate authority must follow. Ballot [SC-081](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) added the schedule. It passed with 25 certificate issuers and 4 certificate consumers voting yes, none voting no, and 5 issuers abstaining. ## Maximum validity schedule | Certificate issued on or after | Certificate issued before | Maximum validity | | --- | --- | --- | | | March 15, 2026 | 398 days | | March 15, 2026 | March 15, 2027 | 200 days | | March 15, 2027 | March 15, 2029 | 100 days | | March 15, 2029 | | 47 days | The Baseline Requirements count a day as 86,400 seconds, and any extra fraction counts as another day. For that reason they say certificate authorities SHOULD NOT issue for the full maximum by default, so certificates are often issued one day short of the limit (for example 397, 199, 99 or 46 days). A certificate issued just before March 15, 2026 with a 398-day validity can stay in service until April 2027, so you will see a mix of longer and shorter certificates until then. ## Domain validation reuse periods The same ballot shortens how long a certificate authority can reuse a completed check that you control a domain. Shorter reuse means the authority asks you to prove control more often, so renewals depend more on your DNS or HTTP validation setup working every time. | From | Domain name and IP address validation reuse | | --- | --- | | March 15, 2026 | 200 days | | March 15, 2027 | 100 days | | March 15, 2029 | 10 days | Subject identity information (the organization details in OV and EV certificates) can be reused for 398 days from March 15, 2026. ## What is Let's Encrypt changing? Let's Encrypt issues 90-day certificates today and is [moving to 45 days](https://letsencrypt.org/2025/12/02/from-90-to-45) in stages: | Date | Change | | --- | --- | | May 13, 2026 | The opt-in `tlsserver` ACME profile issues 45-day certificates | | February 10, 2027 | The default `classic` profile issues 64-day certificates; authorization reuse drops to 10 days | | February 16, 2028 | The default `classic` profile issues 45-day certificates; authorization reuse drops to 7 hours | Let's Encrypt recommends that ACME clients use ACME Renewal Information (ARI) to decide when to renew, or otherwise renew about two thirds of the way through a certificate's lifetime. It also says a fixed renewal every 60 days will no longer work, and that you should monitor renewals and alert when one fails. ## What does this mean for expiry monitoring? Shorter certificates mean more renewals each year and less time between a failed renewal and an outage. A 398-day certificate renewed 30 days early gives you a month of warning. A 45-day certificate renewed at two thirds of its life gives you about 15 days, and the warning window starts sooner after each renewal. Manual renewal stops being practical at these lengths. Use an ACME client such as [Certbot](https://github.com/certbot/certbot) or [cert-manager](https://github.com/cert-manager/cert-manager), then use an independent check such as SSLMonitor to confirm the new certificate is actually being served. ## What thresholds should you use? SSLMonitor uses one `WARNING_DAYS` and one `CRITICAL_DAYS` value for every domain in its list. Set `WARNING_DAYS` below the number of days left when your client normally renews, so a routine renewal does not trigger a warning. Since Certbot 4.0.0, [Certbot renews](https://eff-certbot.readthedocs.io/en/stable/using.html) when less than one third of a certificate's lifetime remains. | Certificate lifetime | Days left at a one-third renewal | Suggested `WARNING_DAYS` | Suggested `CRITICAL_DAYS` | | --- | --- | --- | --- | | 90 days | 30 | 21 | 7 | | 64 days | about 21 | 14 | 5 | | 45 to 47 days | about 15 | 10 | 4 | | 100 to 398 days, renewed by hand | depends on your process | 30 (default) | 7 (default) | Adjust them to match how and when your client renews. If you monitor certificates with different lifetimes, keep two copies of the script with different settings and domain files, each with its own cron line. ## Sources and references - [CA/Browser Forum Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md), sections 4.2.1 and 6.3.2 - [Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) - [Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days](https://letsencrypt.org/2025/12/02/from-90-to-45) - [Certbot User Guide: renewing certificates](https://eff-certbot.readthedocs.io/en/stable/using.html)