Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation
* Nicolas Boullis:
>> In addition, this update tightens the checks for X.509v1 certificates
>> which causes GNUTLS to reject certain certificate chains it accepted
>> before. (In certificate chain processing, GNUTLS does not recognize
>> X.509v1 certificates as valid unless explicitly requested by the
>> application.)
>
> What the hell?
> After upgrading libgnutls13, our server could not anymore connect to our
> LDAP server, apparently because it does not like its certificate chain
> anymore...
Yes, this was sort of expected, but I had hoped that the fallout would
be minimal.
> Our servers use commercial certificates, with "GTE CyberTrust Global
> Root" as the root certificate. It apparently is a v1 x509 certificate...
It's uses 1024 bit RSA, it is more than ten years old, and GTE
Cybertrust does not exist anymore--GTE sold Cybertrust to Baltimore,
Baltimore was sucked in to Betrusted, and Betrusted was bought by
Verizon, so the key material is controlled by someone else these days.
(It does not matter that the self-signature uses RSA-MD5.)
We've received a similar report about a Valicert root, which has
similar issues due to its age (see #514807).
> What is the solution for me? Should I rebuild all the applications and
> libraries that use libgnutls, so that they request to accept x509v1
> certificates? How?
You could try if recompiling gnutls13 with this patch
<http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=97;bug=514807>
enables your setup to work. However, it is unlikely that we will
apply a similar change to lenny. (For etch, the best approach is
still somewhat unclear. But it's either changing gnutls13 in this
way, or keeping the current behavior; modifying all applications is
out of the question.)
You could add your server's certificate to the trusted certificate
store (assuming it's a v3 certificate). Requesting a new certificate
located under a X.509v3 from your certificate provider would also
work. If you mark your server certificates as trusted and remove all
CAs from the trusted CA list, you also isolate yourself from attacks
on careless CAs (which might issue certificates for the domain name of
your LDAP server in an unauthorized fahsion). Unfortuantely, we
haven't got a good way to flag those problematic CAs which are only
good to make browser warnings disappear.
I'm not sure if a X.509v3 version of the root certificate would work,
or would create significant interop problems.
Reply to: