TLS Certificate Validity Calculator
TLS expiry and renewal dates under the 398 day limit.
What it does
Expired certificates break sites at the worst hour. Browsers enforce shorter lifetimes than teams remember, and a missed renewal reads as an outage to every visitor. Dating the expiry at issuance keeps calendars honest.
The tool above adds validity days in UTC. A certificate issued 2026-01-15 with 398 days expires Wed Feb 17 2027, with renewal due Mon Jan 18 2027 under the 398 day public rule. UTC math dodges daylight saving shifts.
The 398 day cap applies to public server certificates issued on or after 2020-09-01 UTC. Validity spans notBefore through notAfter, and vendors recommend staying a day inside the max. Private internal roots play by their own policies.
Thirty days of lead time covers validation, approvals, and deploys across environments. Automate renewal with ACME where the stack allows, and keep a human owner on every certificate that cannot automate.
How to use
- Enter the issued date as YYYY-MM-DD.
- Enter validity days up to 398.
- Read the UTC expiry first.
- Read the renewal date 30 days prior.
- Calendar the renewal with owners.
- Automate renewal where possible.
Formula
- issued
- Certificate start date as YYYY-MM-DD in UTC.
- validity
- Lifetime 1 to 398 days.
- day
- 86400 seconds per day, UTC fixed.
Browser policy caps public TLS server certificates at 398 days for issues on or after 2020-09-01 UTC, with validity defined from notBefore through notAfter. All math here runs in UTC with fixed 86400 second days, so daylight saving never shifts a date. Renew 30 days early to cover validation and deploy time.
Worked example
Example: issued 2026-01-15, 398 days
Defaults: issued 2026-01-15 with 398 days validity. These are also the default values, so the page opens on this answer.
- Issued: 2026-01-15 UTC.
- Validity: 398 days.
- Expiry: 2026-01-15 + 398 = Wed Feb 17 2027.
- Renewal: expiry - 30 = Mon Jan 18 2027.
- Rule check: 398 sits at the public max, so it passes.
- Tool shows Wed Feb 17 2027 with renewal Mon Jan 18 2027 and the 398 day rule.
Reference table
| Issued | Expiry | Renew by |
|---|---|---|
| 2026-01-15 | Wed Feb 17 2027 | Mon Jan 18 2027 |
| 2026-03-01 | Sat Apr 03 2027 | Thu Mar 04 2027 |
| 2026-06-01 | Sun Jul 04 2027 | Fri Jun 04 2027 |
| 2026-12-01 | Mon Jan 03 2028 | Sat Dec 04 2027 |
Limits
- Public TLS rules; private CAs differ.
- Date precision only, no times.
- Ignores revocation and outages.
- Policy changes need rechecking.
Common mistakes
- Counting 365 day years.
- Using local time zones.
- Renewing on expiry day.
- Forgetting SAN coverage.
- Ignoring staging deploys.
Try it yourself
Quick checks. Answers sit tucked under each question.
Issued 2026-06-01, 398 days?
Expiry Sun Jul 04 2027 with renewal Fri Jun 04 2027.
Issued 2026-12-01, 398 days?
Expiry Mon Jan 03 2028 with renewal Sat Dec 04 2027.
Questions
How is expiry found?
Add validity days to the UTC issue date. Here 2026-01-15 + 398 = Wed Feb 17 2027.
Renewal reminder?
Subtract 30 days from expiry. Here Wed Feb 17 2027 - 30 = Mon Jan 18 2027.
Public max validity?
398 days for public certs issued on or after 2020-09-01 UTC.
How are days defined?
Validity runs notBefore through notAfter per RFC 5280, with days of 86400 seconds.
Private CAs same limit?
No. Private roots set their own lifetimes outside browser rules.
Wrong date format?
Type the calendar date exactly; impossible dates like Feb 30 are rejected.