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

Edward Allcutt emallcut at gleim.com
Wed Feb 11 16:50:55 UTC 2009

Simon Josefsson wrote:
> Simon Josefsson <simon at josefsson.org> writes:
>> The reason gnutls-cli doesn't complain is because it contains this code:
>>   /* there are some CAs that have a v1 certificate *%&@#*%&
>>    */
>>   gnutls_certificate_set_verify_flags (xcred,
>> 				       GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
>> 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.
> FWIW, I've worked on this in the gnutls 2.7.x branch.  gnutls-cli no
> longer accepts V1 CAs by default, and there is a new --priority token
> %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it.  The
> priority string approach is what we recommend applications expose to
> their users for configuring GnuTLS internal details.
That's all very well, but it's a rather big change in functionality for 
stable. I doubt it would be acceptable to patch all the relevant apps 
which assume that their list of trusted CAs will actually be used as such.

I can see the same change has been made in libgnutls26 in lenny. Should 
I file several RC bugs against the various modules affected? Bear in 
mind that their documented semantics are "a list of trusted CAs" so I 
think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be entirely appropriate 
in those cases.

Are there any apps which provide a list of trusted certs which should 
not all be considered trusted CAs? If not then perhaps 
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default.

Edward Allcutt
Network Operations

More information about the Pkg-gnutls-maint mailing list