Request: Extend configurable CRL timelines for offline CA purposes

[francinum]

The configurable CA validity implimented as part of #208 is greatly appreciated, though extending the validity window further would ease the annoyance involved in the deployment of offline roots.

I'm not sure if you'd rather things like this be issued as discussions or as proper issues, How would you prefer I provide feedback like this in the future? I recently filed a batch of issues that may have been better bundled as in #207, Do let me know. And as I've not stated this before, Thanks for putting together this project, it's strange to me that there's nothing else that really comes close to this project's feature set that isn't licensed at enterprise software rates.

[dogarethebest]

@NeySlim have you seen this

I don’t think they check discussions as often

[NeySlim]

no I didn't

[NeySlim]

Thanks francinum — this is a fair ask, and sorry for the late reply (I do watch issues more than discussions; filing feature requests as issues is perfectly fine, one per topic is ideal).

Good timing on the question: I just extended the CRL validity window specifically with offline roots in mind. The cap on validity_days is raised from 365 to 1825 days (5 years) — RFC 5280 puts no limit on nextUpdate, and an offline root that can't re-sign CRLs on schedule is a legitimate reason to go long. The UI (CRL & OCSP page) now offers 90d/180d/1y/3y/5y options and shows a warning beyond 1 year since relying parties may cache stale revocation data for the entire window.

This will ship in 2.206.

And thank you for the kind words about the project — feedback like yours (and your issue batch around #207/#208) is exactly what keeps it moving.