1

Which of these options are actually in line with standards?

In software that generates SSL client certificates to hand out to client software for authentication into a closed system, should the NotBefore field be set to the time of generation, or that time subtracted by some leeway?

The main points of concern here are:

  • Clock-skew between the generating server and the authenticating server.
  • Clock-skew on the client OS.
  • Any vulnerabilities that arise from going too permissive on the NotBefore date.

The options are:

  1. Include the leeway in the NotBefore date.
  2. Don't add leeway to the NotBefore date but instead cater for it during validation. (At a glance, this doesn't appear to be a common option, so likely involves hacking low-level SSL implementation on server software.)
  3. Don't add leeway and handle clock-skew directly on the servers. (This doesn't handle the client, but a small sample of APIs I looked at (namely .NET Framework) don't seem to mind choosing yet-to-be-valid certificates.)
Improve this question
2
  • Isn't this only a problem at the very beginning of a client certs' life cycle? How often will these client certs be replaced? If the answer is "once every 3 years" then I don't think you have to worry about notBefore too much. FWIW: Mozilla allows Minor tweaking for technical compatibility reasons. – StackzOfZtuff Mar 8 '17 at 4:34
  • @StackzOfZtuff Yeah, it's an edge case in terms of life cycle, but they're replaced (auto-refreshed) by the client software every month so the result multiplied by users is possibly significant enough impact on support that I want to at minimum get a bearing on options and cost. Very interesting link, thanks for that. – antak Mar 8 '17 at 5:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.