** 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=i...@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=i...@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=i...@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=i...@valicert.com
3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2
Policy Validation
Authority/CN=http://www.valicert.com//emailaddress=i...@valicert.com
i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2
Policy Validation
Authority/CN=http://www.valicert.com//emailaddress=i...@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:
+
+ math...@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
+
+ math...@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.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
