On Tue, Mar 31, 2015 at 10:11 AM, Stephen Farrell <[email protected]> wrote: > Turns out after a bit of searching, I'd installed the new > cert too soon, and when I tested it, a "dunno" OCSP > response was sent before the responder had seen the new > cert and that OCSP response has now been cached for some > unknowable (to me) number of hours in who-knows-what > places. And that caching behaviour has changed since the > last time I got a cert from the same provider a few months > ago. So I reverted my apache to the old cert and will > try install the new cert again tomorrow.
This sounds predominantly like a CA problem of their databases not syncing up soon enough mixed with a software problem of trying to staple a 'dunno' ocsp response. > That's exactly that kind of thing I'd love to see fixed > with acme and that is not handled by CMP, CMC, PKCS#10, > EST or SCEP. At least I don't believe there's a standard > way of getting the right thing to happen with those > without some proprietary extension/surroundings. The software can fix this with some sanity checks upon cert install. (I know IIS doesn't do this either and is happy to staple a revoked response from the CA) If we do want to put these type of considerations in the draft, maybe the security considerations section is the best place. Something along the lines of: When preparing to use the new certificate received from a issuance or refresh, the client software should check that the OCSP response from the certificate authority is valid before enabling the new certificate for use in the server system. If the OCSP response is requested too early by the server system, a 'revoked' or 'unknown' OCSP response may be cached and cause browsers to fail connection attempts. -cem _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
