On 20.09.2013 18:25, Nikolaus Rath wrote:
Jochen Bern Jochen.Bern@LINworks.de writes:
On 20.09.2013 05:27, Nikolaus Rath wrote:
So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Imagine the CA (or one of the intermediate CAs) getting compromised and corresponding revocations becoming available to your machine (by OS updates, OCSP, whatever) before you hear of the incident.
FWIW, I still don't see why I'd use verify=3 in that case.
Because verify=4 doesn't know the CA chain (barring the oddity reported by Thomas) and thus would not consider the server cert invalid because of the CA cert revocation.
Whether you *want* that to happen is a somewhat different question. Under normal circumstances, one would expect such a situation to result in the server operators installing a new server cert from another CA, at which point your stunnel setup will stop working, anyway. (Unless the attacker was able to snarf the server's privkey from the CA's archives and has already set up a MitM attack against *your* connections.) In other words, using 4 instead of 3 where possible gains you maybe a couple days of continued operation, at the expense of probably not learning that fast *how* the CA was compromised and what that means for the trustworthiness of the server cert.
(I currently have another case at hand where the difference would be much more pronounced, though. IMHO the CA blundered there - as in, the server cert is valid until late 2015, but one intermediate CA's cert expires early in 2014. Ho hum ... !)
Regards, J. Bern