Feature Request: Enforce --days renewal schedule and add pre-issuance validity check

[coreydavis-emerson]

Hello,

We are trying to implement a robust, long-term certificate renewal policy that minimizes operational risk. The current renewal logic for short-lived certificates presents a challenge.

We completely understand and agree with the safety feature that prevents a logically impossible renewal (e.g., requesting a 10-day renewal for a 7-day certificate). However, the current implementation also overrides the schedule in scenarios that are logically sound, such as requesting a 5-day renewal for a 50-day certificate. This forces a 1-day renewal buffer, which is too small for our risk management needs in a large-scale infrastructure. If a daily cron job were to fail, we would have less than 24 hours to fix the issue before services are impacted.

Even with long-lived certificates (e.g., 365 days), where the default 60-day renewal works as expected, we lack granular control. We may have a business need to renew a specific long-lived certificate 5 days before it expires, but the current logic does not easily accommodate this without manual intervention.

Proposed Solution
We propose a two-part enhancement that would provide both safety and complete user control:

1. Introduce a New --days-override Flag: This flag, when used with --issue or --renew, would signal the user's intent to take full control of the renewal schedule.

When --days-override is present, the script would strictly honor the value passed to the --days flag, calculating the renewal from the issuance date.

This would bypass the automatic "renew 1 day before expiration" behavior for short-lived certs, allowing us to define a custom safety buffer (e.g., a 7-day window for a 47-day certificate).

2. Add a Sanity Check for the Override Flag: To prevent mistakes when using this new power, the pre-issuance sanity check should be tied directly to the --days-override flag.

If --days-override is used, the script would first check if the requested renewal period (--days) is greater than the certificate's known validity period.

If the math is impossible, the script would print a warning and exit, forcing the user to correct the request.

Example Warning: Error: --days-override failed. Requested renewal period (60 days) is greater than the certificate's validity (47 days).

This approach provides a clear, intentional way for advanced users to enforce a specific renewal schedule while maintaining safe defaults for everyone else.

Test Data Context
Our testing with acme.sh v3.1.2 confirms the current behavior:

365-Day Certificate: Correctly renews at the default of 60 days.

50-Day Certificate: A --days 5 request resulted in a renewal scheduled for day 49.

10-Day Certificate: A --days 5 request resulted in a renewal scheduled for day 9.

We believe this proposed solution would be a significant improvement for users focused on operational stability and long-term resilience.

Thank you for your consideration and for your work on this project.

[saudiqbal]

I requested this feature long time ago and there was a PR but nothing happened - #4457 It should be added to acme.sh with negative days.

Currently I am using --days 83 to renew 7 days before the 90 days expiry which will stop soon when the lifetime will be reduced to 47 days.

[coreydavis-emerson]

I'm pretty novice when it comes to shell scripting. I worked on the issue with GitHub CoPilot using my non-work github account and came up with a fix that works. My fix has additional logic for when the requested renewal date is outside of the certs expiration date. See Pull request 6752

[numo68]

To be fair I don't understand the logic behind hardcoding one day if --valid-to is specified. If there is a reason to disallow concurrent usage with --days (see also #4113), something like "renew after 2/3 time" would make much more sense to me. One day means one hiccup and the certificate is expired. It even seems like the math is using 86400 seconds exactly, meaning that a jitter in the cron execution might cause it to in fact renew just a few seconds before (or after) due.