Hi Peter, Just to confirm: the scenario you're using to contrast to the one described by Viktor (and Nico) is a scenarios in which the certificates expire at "never" (99991231235959Z)?
I think that at least some people are contrasting against something other than that... Thanks, Ben On Mon, Mar 08, 2021 at 03:21:22AM +0000, Peter Gutmann wrote: > Viktor Dukhovni <[email protected]> writes: > > >But if the signal is not ignored, and proper automation is applied, > >reliability actually improves. > > No, it drops. You're going from a situation where you've eliminated any > chances of outages due to expired certs to one where you get to play Russian > roulette every single day: Will the cert renewal work, or will it fail for > some reason? Let's spin the cylinder and see if this is the day our grid goes > down. > > Even if you somehow create a 100% successful magical process for replacing > certs that never ever fails, you're now introduced another possible failure > situation, with certs changing constantly there's a chance that something that > relies on them can't handle a new cert, for example because an issuing CA has > renewed as well or something similar. > > It's just building in more and more opportunities for failure from a mechanism > that's supposed to be making your infrastructure more robust, not less. > > Peter. > > > _______________________________________________ > TLS mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!GaaCbhUsGvSdgqi6crkwhODrap4fYzdX6pgIOq4zyhG9nX88r3GTRHuFOsw1ew$ > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
