* 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. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org