Bug#514807: Regression in libgnutls security update

[Edward Allcutt]

Florian Weimer wrote:
> * Edward Allcutt:
> 
>> I believe this is a significant regression in stable because at least
>> one widely used CA (godaddy) still issues certificates with a chain
>> ending in a v1 root (ValiCert Class 2).
> 
> Are we talking about this certificate?
> 
>         Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
That's the one.

> It's not just a X.509v1 certificate.  It's ten years old, it's just
> 1024 bits, and ValiCert does not exist anymore as an organization
> (thus the DN is invalid).
I'm not any happier about it than you are, but it seems godaddy are 
still issuing certs using that root.

> Simon, could we make the harmless variant (X.509v1 certificate set as
> trusted is accepted as a root CA, but intermediate X.509v1
> certificates aren't accepted) the default in etch?
> 
>> Godaddy appears to have a newer v3 root but I don't know how widely
>> deployed this is. It is not in the etch ca-certificates package for
>> example.
> 
> Which root are you referring to?
They're all available at https://certs.godaddy.com/Repository.go.

The main new one seems to be "Go Daddy Class 2 CA" which is in lenny 
ca-certificates as 
/usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt

The other new one is "Starfield Services" which is in lenny 
ca-certificates as 
/usr/share/ca-certificates/mozilla/Starfield_Class_2_CA.crt

Neither of these are in etch, and in fact neither of them seem to have 
the critical flag set for their "X509v3 Basic Constraints", which I've 
seen mentioned as an issue in other bug reports.

-- 
Edward Allcutt
Network Operations