[Bug 305264] Re: gnutls regression: failure in certificate chain validation

[Mathias Gug]

** Description changed:

  I noticed recently that landscape-client could no longer contact our
  staging server. Fortunately, contacting the production server is still
  ok.
  
  This command is an easy way to reproduce the problem. It is failing
  against staging.landscape.canonical.com:
  
  gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt
  staging.landscape.canonical.com
  
  I tried it in dapper, feisty, gutsy, hardy and intrepid. It only works
  in feisty, and I'm guessing it's because feisty is EOL'ed and didn't get
  an update.
  
  I concentrated the rest of my tests in dapper.
  
  With libgnutls12_1.2.9-2ubuntu1_i386.deb it works.
  With libgnutls12_1.2.9-2ubuntu1.3_i386.deb it breaks.
  
  Here is the chain as seen by gnutls against staging.landscape.canonical.com:
  [0]
  Subject's DN: O=*.landscape.canonical.com,OU=Domain Control Validated,CN=*.landscape.canonical.com
  Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
  
  [1]
  Subject's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
  Issuer's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
  
  [2]
  Subject's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
  Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info@valicert.com
  
  [3]
  Subject's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info@valicert.com
  Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info@valicert.com
  
  
  Notice that the last certificate in the chain is the CA certificate, which is self signed. I wonder if the recent security fix broke that:
      - debian/patches/91_CVE-2008-4989.diff: don't remove the last certificate
        if it is self-signed in lib/x509/verify.c
  
  Here is openssl's chain against the same site (staging):
  Certificate chain
   0 s:/O=*.landscape.canonical.com/OU=Domain Control Validated/CN=*.landscape.canonical.com
     i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
   1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
     i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
     i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
   3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
     i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
  
  Openssl's s_client tool works, btw.
+ 
+ TESTCASE for openldap SRU:
+ 
+ 1. Generate a V1 root CA. Can be done with an openssl configuration that
+ does not use any x509 extensions. Make sure that the generated root CA
+ is a V1 root CA.
+ 
+ 2. Generate a client private key and a V1 certificate signed by the root
+ CA above. Note that the CN of the certificate has to match the fqdn of
+ the test system.
+ 
+ 3. Install slapd and ldap-utils on a test system and configure slapd to
+ use TLS:
+ 
+   a. Enable TLS in cn=config backend:
+ 
+ mathiaz at t-slapd-i:~$ cat enable-ca.ldif 
+ dn: cn=config
+ add: olcTLSCACertificateFile
+ olcTLSCACertificateFile: /etc/ldap/cacert.pem
+ 
+ dn: cn=config
+ add: olcTLSCertificateFile
+ olcTLSCertificateFile: /etc/ldap/newcert.pem
+ 
+ dn: cn=config
+ add: olcTLSCertificateKeyFile
+ olcTLSCertificateKeyFile: /etc/ldap/key.pem
+ 
+ mathiaz at t-slapd-i:~$ ldapmodify -D "cn=admin,cn=config" -x -w mypwd -f
+ enable-ca.ldif
+ 
+   b. Copy the root CA certificate to /etc/ldap/cacert.pem, the host certificate to  /etc/ldap/newcert.pem and the host private key to /etc/ldap/key.pem. Make them owned by the openldap user and group. 
+   c. Append the root CA certificate (/etc/ldap/cacert.pem) to the host certificate file (/etc/ldap/newcert.pem).
+   d. Enable slaps in /etc/default/slapd.
+   e. Restart slapd.
+ 
+ 4. Make sure that slapd is correctly configured to use TLS:
+   a. Downgrade libgnutls to the version in the release (not the one in -security, -update or  -proposed).
+   b. Check that ldapsearch works correctly against the ldap server via ldaps:
+ 
+ ldapsearch -D "cn=admin, dc=vmnet" -b "dc=vmnet" -x -w mypwd -H
+ ldaps://t-slapd-i./
+ 
+ The command above should return a dump of the ldap database and not a
+ connection error.
+ 
+ 5. Upgrade libgnutls to the latest version available. The command above
+ should return a connection error:
+ 
+ ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
+ 
+ This is the regression.
+ 
+ 6. Update slapd, ldap-utils and libldap-2.4-2. The command above should
+ return a dump of the database and not a connection error.

** Changed in: openldap (Ubuntu Intrepid)
       Status: Triaged => Fix Committed

-- 
gnutls regression: failure in certificate chain validation
https://bugs.launchpad.net/bugs/305264
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in ubuntu.