Related to T204997: certcentral: delay deployment of renewed certs to wait out skewed client clocks
<bblack> while we're on the certcentral stuff in general, another longer-term thing we'll have to eventually solve, related to the waiting-for-clock-skew period and such: <bblack> is handling client-side integration of OCSP stapling reliably. Which is going to mean shipping the client multiple certs when going through a renewal. <bblack> (the old solution doesn't do any of this of course) <bblack> the idea is that for OCSP stapling to work reliably, the client-https-service has to have the cert ahead of time, to run a local OCSP fetch and populate. <bblack> so you can imagine a hypothetical model like: <bblack> CC manages it more like a "set" of overlapping certs: the old one it's renewing well ahead of time, and the new renewal it has just-recently fetched from LE (but is perhaps not "live" yet, because we're waiting a day for clock skew before deployment) <bblack> it could ship the whole set to the client (multiple files), and an indicator as to which is live <bblack> so the old one would still be "live" initially while we wait clock skew, but having the new one sent over lets the client start prefetching OCSP data for it, so that later when it becomes live the OCSP is ready to go. <bblack> there's probably like 10 ways to factor that out, and ? about how much of the state is managed client-side or CC-side