On 20.09.2013 04:30, Javier wrote:
But a bit contradictory to accept a certificate that has been issued by a CA you don't trust, just for the main purpose of establish an SSL connection.
Why? I can easily see a provider (say, e-mail) buying a server cert from an ultra-el-cheapo CA that *I* wouldn't trust to hold the door open for me. As long as that CA only gets the CSR from the provider (and never sees the private key), there's no reason why I shouldn't trust *the keypair*, though. And the server cert effectively is the embodiment of that keypair / the pubkey in the SSL exchange. (And "I don't care about the CA, just gimme encryption to prevent eavesdropping" *is* how web browsers used HTTPS for quite some time. Which then got supplanted by "everyone works along the list of CAs that come preinstalled in browsers today" ... :-S ) 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. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel