[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates
andrew at sslmate.com
Wed Feb 1 05:15:35 UTC 2017
On Tue, 31 Jan 2017 20:37:19 -0800
Ryan Sleevi via Public <public at cabforum.org> wrote:
> Except what we're seeing is that subscribers aren't renewing annually
> - they're renewing every 13 months (or 27 or 39).
> That is, it's unclear that the practical benefit of the buffer is
> there, but it'd be great to understand if something is being missed.
> Put differently, why cant CAs begin reaching out to their customers
> one month before it expires (e.g. on month 11)? What makes month 12
> more special than month 11, from the perspective of the
> For that matter, it would seem like 12 months is *more* customer
> friendly, because then they can get into an annual habit of replacing
> their cert. If it were 13 months, and CAs continued the current
> practice of notifying at some point of (T-1 month / T-2 months), then
> every year, the subscriber will be installing the cert one month
> later - until suddenly they find themselves in that
> November/December/January "production freeze" and find themselves
To avoid the expiration date drifting every year, a renewed
certificate's notAfter date must be exactly one year after the current
certificate's notAfter date. With a 12 month limit, the CA could only
do this by issuing the renewed certificate exactly when the current
certificate expires, which is clearly unworkable since it allows no
time for cutover.
In contrast, a 13 month limit would allow a CA to issue the renewed
certificate up to one month before the current certificate expires,
with a validity period between 12 and 13 months as necessary to make
the expiration date sync up. This is far friendlier.
More information about the Public