Big CA certificate bundle causes problems with GnuTLS 3.0.11

Sam Varshavchik mrsam at
Wed May 30 01:04:48 CEST 2012

Nikos Mavrogiannopoulos writes:

> In the TLS protocol the server advertises its CA certificates so a
> client would know which certificate to present. If a server trusts all
> the certificates in the system, the server would advertise all of them
> (their DNs actually).

IIRC, this occurs only when client certificates are enabled. Yes, I would  
think that in that case only the certificates that the server trusts, should  
be loaded.

I would think that in most situations an organization would have only their  
own CA trusted, and loaded into a TLS server. I suppose I can imagine a  
situation where an org would, in some context, decide that accepting a  
client cert signed by any public CA to be acceptable, and then use it for  
some particular purpose. But I don't think this would be the case for most  
practical situations. And, in those cases, loading the public CA certs would  
be a security hole. Depending on the purpose the client cert is being used  
for, and how, it wouldn't take much imagination to get some public CA to  
sign something that looks good enough to 0wn JOO.

So, I would take a hard look at why someone really wants to load a public CA  
bundle, in the first place, to validate client certs.

I suppose someone might want, for some odd reason, to blow a wad of cash on  
having some public CA sign some certs, for their clients, even though it's  
trivial to set up your own cert, and do it yourself for free. But, still, in  
that case, at the very least you should only load /that/ CA, and not the  
whole bundle.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20120529/fabdd136/attachment.pgp>

More information about the Gnutls-help mailing list