Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay deployment of certificates to mitigate client’s clock issues #8456

Closed
Seb35 opened this issue Nov 15, 2020 · 3 comments
Closed

Delay deployment of certificates to mitigate client’s clock issues #8456

Seb35 opened this issue Nov 15, 2020 · 3 comments
Labels
area: cert management area: install feature request needs-update priority: unplanned Work that we believe should be done, but does not have a higher priority.

Comments

@Seb35
Copy link

Seb35 commented Nov 15, 2020

According to this study there is a non-negligible number of clients who have certificate errors because of their misconfigured clock. The study gives the numbers of 6.7% of clients whose the clock is more than 24h late and 0.05% whose the clock is more than 24h ahead (see part 7.1 of the study and figure 4).

If I’m not mistaken, the notBefore attribute of Let’s Encrypt certificates is one hour before the current hour, probably to mitigate clock issues. Instead of proposing a change of the notBefore attributes of LE certificates (this is perhaps imposed by CA/Browser Forum or other security rules), this feature request proposes to improve the quality of the renewal process of certificates issued by certbot by delaying the deployment of renewed certificates to mitigate much more clock issues.

Currently the newly-renewed certificate is deployed immediately. With this new scenario the newly-renewed certificate would be delayed a few days (e.g. 5 days) before being deployed and becoming active, obviously if the previous certificate is still valid during this delay (and a bit more to take into account clients whose the clock is ahead).

The delay should be configurable and should be zero by default to keep the current scenario and to force sysadmins to consciously activate this delay, given it could be not expected.

@Seb35
Copy link
Author

Seb35 commented Nov 15, 2020

I wrote a preliminary patch for this scenario and will submit it in a few hours/days. I used a slightly more complex delay model of:

  • immediate deploy if the previous certificate expires in less than 2 days;
  • a linear transition between a 2-days and a 5-days delay between 2 days and 9.5 days before the previous cert expiration (specifically a deployment at {notBefore of new cert} + 2/3 x ( {notAfter of old cert} - 2 days - {notBefore of new cert} );
  • a 5-days delay if the previous cert expires in more than 9.5 days.

But the delay model could be discussed to find something sensible and probably sufficiently simple.


Also I was aware of the study on this task in Wikimedia environment, so cross-linking with it.

@alexzorin alexzorin added area: cert management area: install feature request priority: unplanned Work that we believe should be done, but does not have a higher priority. labels Nov 16, 2020
@github-actions
Copy link

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

@github-actions
Copy link

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: cert management area: install feature request needs-update priority: unplanned Work that we believe should be done, but does not have a higher priority.
Projects
None yet
Development

No branches or pull requests

2 participants