We’ve had an interesting situation come up that isn’t clearly covered in the
BRs.
We have a customer who has a system that does not have a persistent clock when
it is first unboxed. When it powers on, it starts counting from a given point
in time (for example 2017-01-01 00:00:00Z). This device has network access and
one of the tasks it does early on is to reach out to a server to get a firmware
update and configuration information. Having some security smarts, the
customer assured connections are all made via TLS and they do have certificate
checking enabled.
You might have already spotted the problem — at some point the server
certificate is going to get renewed and will probably have a notBefore date
that is after 2017-01-01. This will cause the firmware and configuration
update to fail.
They have asked if they could get a new certificate for the server with a
notBefore date in the past — notably setting it early enough to pass validation
by just unboxed devices. This would be issuing with the same subject
information and domain names that have been in previous certificates. The
issued certificate will meet all the requirements for new certificates issued
today.
This was discussed last September:
https://cabforum.org/pipermail/public/2016-September/008450.html
<https://cabforum.org/pipermail/public/2016-September/008450.html>, but I never
brought it to ballot.
So I have two questions:
1) Does anyone think setting a notBefore well before the issuance dates a
problem, as long as the certificate includes a timestamp that represents the
issuance date and the CA previously issued a certificate for the same domain
name(s) to the same applicant that has a validity period that spans from the
notBefore to issuance date?
2) What is the latest acceptable notAfter date? 39 months (or 825 days in the
future) from the notBefore date or from the issuance date?
Thanks,
Peter
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
