Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"

[Edward Allcutt]

retitle 514807 X.509v1 CA certs no longer trusted implicitly
thanks

Simon Josefsson wrote:
> Edward Allcutt <emallcut at gleim.com> writes:
>> Simon Josefsson wrote:
>>> I suspect the problem is that you have a RSA-MD5 signature somewhere in
>>> the certificate chain.
>> Nope, already checked that... gnutls-cli does work after all. It's the
>> other modules linked to libgnutls that are failing.
> 
> I believe the problem is that you have a V1 CA, which isn't permitted by
> default by libgnutls.
Only since this security update. I'm not saying that not trusting VA CAs 
shouldn't be the correct ideal behavior but it does seem very 
impractical right now. At the very least, can you postpone this change 
in functionality until lenny?

> I don't recommend doing the same in other applications, and we should
> probably remove it from gnutls-cli too.  It may be useful to create a
> parameter in other tools to enable the flag on a per-case basis, though.
Those applications which need to change their flags should of course be 
patched to do so, but not in stable. This seems like a change in the API 
of libgnutls. A change towards what is documented, granted, but a change 
nonetheless and away from what most applications seem to expect.

> For explanation of why V1 CA's are bad, see:
I understand that. The argument against 
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the argument 
against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak, especially 
given most applications give a list of trusted CAs, not non-CAs.

In addition, at least one very popular CA still seems to use a v1 cert 
as their root. They have new v3 root certs however these aren't included 
in ca-certificates until lenny.

> I'm tagging this as wontfix since this is the documented and intended
> behaviour.  I am sorry you had to notice it through an upgrade --
> however the reason for the upgrade was to close this hole.
Hmm, I thought the reason for the upgrade was to close this hole:
CVE-2008-4989. Fixing this deviation from documentation was just a 
side-effect.


-- 
Edward Allcutt
Network Operations