[GH-ISSUE #839] [Feature] Custom Certificate Lifetime/Expiration #571

New issue

Closed

opened 2026-03-03 01:04:23 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 01:04:23 +03:00

Owner

Originally created by @FarrelF on GitHub (Jun 30, 2025).
Original GitHub issue: https://github.com/certimate-go/certimate/issues/839

功能描述 / Description

This feature allows users to issue TLS certificates with varying expirations, it is also supported by several CA providers among which Google Trust Services is capable of issuing certificates with expirations from the next 1 to 90 days since issued although a minimum of 3 days is recommended by them to prevent system clock skew.

This is not same as Let's Encrypt's shortlived profile, which has a validity of only 6 days, as of yet Let's Encrypt does not able to issuing TLS certificates with varying expirations.

请求动机 / Motivation

With varying expiration, this allows users to issue shorter TLS certificates by other supported CA, so that we not dependant on revocation system and when certificate renewal is fully automated, we should no need to use TLS certificate with excessively long lifetimes (like 3 months), as we can renew it on daily or weekly basis.

Another than that, the TLS certificate lifetime officially just reduced and it start from these dates:

March 15th, 2026, the maximum lifetime will be 200 days
March 15th, 2027, the maximum lifetime will be 100 days
March 15th, 2029, the maximum lifetime will be 47 days

So we can prepare to make fully automated TLS certificate renewal even using another CA as soon as possible before these date, being able to prepare it sooner would be better.

其他 / Miscellaneous

Lego seems can issue TLS certificates with varying expiration (notBefore and notAfter) as you can see here https://github.com/go-acme/lego/issues/1714 and here (see lego help run and lego help renew), but this require users to specify an absolute date with RFC3339 format which is i'm afraid that these certificates will not be automatically renewed.

acme.sh seems have better implementation for this, as you can see here acme.sh allows users to varying expiration with relative format, so we no need to input an complete date with RFC3339 format and these certificates can be renewed automatically before expired.

Thank you for this great app that helped me to fully automate my TLS certificates renewal 😊

贡献 / Contribution

我乐意为此贡献 PR！ / I am interested in contributing a PR for this!

Originally created by @FarrelF on GitHub (Jun 30, 2025). Original GitHub issue: https://github.com/certimate-go/certimate/issues/839 ### 功能描述 / Description This feature allows users to issue TLS certificates with varying expirations, it is also supported by several CA providers among which Google Trust Services is capable of issuing certificates with expirations from the next 1 to 90 days since issued although a minimum of 3 days is recommended by them to prevent [system clock skew](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46359.pdf). This is not same as Let's Encrypt's `shortlived` profile, which has a validity of only 6 days, as of yet Let's Encrypt does not able to issuing TLS certificates with varying expirations. ### 请求动机 / Motivation With varying expiration, this allows users to issue shorter TLS certificates by other supported CA, so that we not dependant on revocation system and when certificate renewal is fully automated, we should no need to use TLS certificate with excessively long lifetimes (like 3 months), as we can renew it on daily or weekly basis. Another than that, the [TLS certificate lifetime officially just reduced](https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days) and it start from these dates: - March 15th, 2026, the maximum lifetime will be 200 days - March 15th, 2027, the maximum lifetime will be 100 days - March 15th, 2029, the maximum lifetime will be 47 days So we can prepare to make fully automated TLS certificate renewal even using another CA as soon as possible before these date, being able to prepare it sooner would be better. ### 其他 / Miscellaneous [Lego](https://github.com/go-acme/lego) seems can issue TLS certificates with varying expiration (`notBefore` and `notAfter`) as you can see here https://github.com/go-acme/lego/issues/1714 and [here](https://go-acme.github.io/lego/usage/cli/options/index.html) (see `lego help run` and `lego help renew`), but this require users to specify an absolute date with RFC3339 format which is i'm afraid that these certificates will not be automatically renewed. [acme.sh](https://github.com/acmesh-official/acme.sh) seems have better implementation for this, as you can see [here](https://github.com/acmesh-official/acme.sh/wiki/Validity) acme.sh allows users to varying expiration with relative format, so we no need to input an complete date with RFC3339 format and these certificates can be renewed automatically before expired. Thank you for this great app that helped me to fully automate my TLS certificates renewal 😊 ### 贡献 / Contribution - [ ] 我乐意为此贡献 PR！ / I am interested in contributing a PR for this!