Description of problem: After upgrading my Fedora 20 to 21 my system could no longer connect to 2 of our 3 LDAP servers. Downgrading openldap to 2.4.40-1.fc21 fixed the issue. The only change (according to the changelog is) between this version and the broken one is: enhancement: support TLSv1 and later (#1160466) It seems this patch breaks my connections to the only TLS1.1 and 1.2 capable LDAP servers and only works for the LDAP server which only supports TLS1.0. So it seems to break the very thing is was supposed to add? [root@lucifer ~]# ldapsearch -x -d1 -H ldaps://<ip address sensored> ldap_url_parse_ext(ldaps://<IP address sensored>) ldap_create ldap_url_parse_ext(ldaps://<ip address sensored>:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP <ip address sensored>:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying <ip address sensored>:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: certdb config: configDir='/etc/openldap/cacerts' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11 error. TLS: skipping 'cacert.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: loaded CA certificate file /etc/openldap/cacerts/f4033bb2.0 from CA certificate directory /etc/openldap/cacerts. TLS: certificate [E=security.be,CN=SENSORED.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE] is valid TLS: error: connect - force handshake failure: errno 0 - moznss error -12256 TLS: can't connect: TLS error -12256:SSL received a malformed Certificate Request handshake message.. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) It seems the NSS validations says the certificate is valid but then throws error 12256. The name to which I connect is configured in the subject alt name of the server certificate (not the CN). I see in bug 1160467 this is also scheduled for RHEL 6.7? Hopefully this regression is fixed before it gets merged. Version-Release number of selected component (if applicable): openldap-2.4.40-2.fc21 How reproducible: Always Steps to Reproduce: 1. Install openldap-2.4.40-2.fc21 2. Run ldapsearch -x -d1 -H ldaps://<URI OF TLS1.1 capable server> 3. Actual results: Error 12256 Expected results: LDAP results as it was in Fedora 20 and up to version 2.4.40-1.fc21 Additional info:
Hi, I've done some debugging and I can only reproduce this when I set the olcTLSVerifyClient value to 'allow'. If I don't specify this parameter, the SSL/TLS connection works. As soon as I add back this parameter in our config, the error pops up again. So it seems the patch(es) in the 2.4.40-2.fc21 upload breaks SSL connections if the server allows client certificates. Regards, Rik
That patch was a backport and I asked people to verify the fix. ITS 8002 is probably invalid, since the Fedora patch is different. Also, upstream usually doesn't care about Fedora/Red Hat builds. Would you mind sharing your server and client configuration to reproduce this?
Hi Jan, I seem to have misplaced my test VM's on which I debugged this, but my conclusion was that removing the olcTLSVerifyClient configuration parameter from our configuration "fixed" it. We have most of our LDAP servers on Debian Wheezy (which link openldap against gnutls) and our clients on CentOS 6 (and 7). I do think I reproduced this also with a CentOS 7 server but I'm no longer sure. If you can not reproduce it with an ldap server which has an SSL certificate and the olcTLSVerifyClient parameter set to 'allow', I will try to reproduce it again. This could take me a few days as I'm busy and out-of-office for a few days. Rik
Created attachment 985116 [details] base config to reproduce on a Debian Wheezy (gnutls linked) server
Created attachment 985117 [details] ldif to add the olcTLSVerifyClient option
Created attachment 985118 [details] ldif to remove the olcTLSVerifyClient option
Hi Jan, I've added 3 files which should help you reproduce the problem. Attachment 985116 [details] is an ldif of the configuration of the server. I was only able to reproduce it when the server is on Debian Wheezy (slapd linked against gnutls) but not (yet) on Fedora 21 as the server. 1. Set up a minimal debian wheezy with slapd installed and the provided config. Generate a CA certificate and server certificate signed by this CA. Use the server certificate in the configuration. 2. Set up a Fedora 21 client to use the CA certificate in its trust store. 3. Verify that ldapsearch -x -H ldaps://my-ldap-server works. 4. Run 'ldapmodify -Y EXTERNAL -f add-olcTLSVerifyClient.ldif -H ldapi:///' on the server to add the option. 5. Rerun the command from 3 on the fedora client and see that it fails now. 6. Downgrade the version of openldap on Fedora to the one before the TLS 1.2+ patch got applied and see that it works without this patch applied. Let me know if you need any more information. Regards, Rik
Thanks! I'll look into it.
Additionally, I noticed that you had this line in your configuration: olcTLSCipherSuite: SECURE256:!VERS-SSL3.0:!3DES-CBC According to slapd-config(5), to require TLS1.1, you should use: olcTLSProtocolMin: 3.2 I don't know anything about gnutls cipher suites, so I don't know if your config is actually correct. Could you please try to remove the "olcTLSCipherSuite" attribute and replace it with "olcTLSProtocolMin: 3.2" to see if it changes anything?
With current Fedora 21 using NSS certificates: $ sudo certutil -L -d /var/tmp/certs/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI server-cert u,u,u CA certificate CTu,u,u client-cert u,u,u I have a database with a self-signed CA cert, and a server and client certificate both signed by the CA. $ sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" -s base # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /var/tmp/certs olcTLSCertificateFile: "server-cert" olcTLSCertificateKeyFile: /var/tmp/certs/password olcTLSVerifyClient: allow olcTLSProtocolMin: 3.2 I have the server running with TLS1.1 set up and olcTLSVerifyClient set to allow. $ cat /etc/openldap/ldap.conf TLS_CACERTDIR /var/tmp/certs TLS_CERT client-cert TLS_KEY /var/tmp/certs/password SASL_NOCANON on My clients are set op as well. $ sudo ldapsearch -x -H ldaps://jsynacek-ntb-work # extended LDIF # # LDAPv3 # base <> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 I got no results, since there's nothing there to get, but the connection works. On the server, I'm seeing: 54ca09c6 >>> slap_listener(ldaps://jsynacek-ntb-work) 54ca09c6 connection_get(19): got connid=1000 54ca09c6 connection_read(19): checking for input on id=1000 TLS: certdb config: configDir='/var/tmp/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /var/tmp/certs prefix . TLS: certificate 'server-cert' successfully loaded from moznss database. TLS: no unlocked certificate for certificate 'CN=jsynacek-ntb-work,CN=server'. TLS: certificate [CN=jsynacek-ntb-work,CN=server] is valid 54ca09c6 connection_get(19): got connid=1000 54ca09c6 connection_read(19): checking for input on id=1000 TLS certificate verification: subject: no certificate, issuer: no certificate, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 1, cache not reusable: 0 54ca09c6 connection_read(19): unable to get TLS client DN, error=49 id=1000 54ca09c6 connection_get(19): got connid=1000 54ca09c6 connection_read(19): checking for input on id=1000 It seems to be working correctly. Am I missing something?
Hi, Regarding comment 9: When I remove the olcTLSCipherSuite line and fall back to the default, it seems to work. The olcTLSProtocolMin is an unknown parameter on the Debian Wheezy version. Regarding comment 10: We have/had olcTLSVerifyClient set to allow but our clients don't send a client certificate. Is your server on Debian Wheezy with openldap compiled against gnutls? Now it seems to work if I either remove the olcTLSVerifyClient option, or drop the olcTLSCipherSuite option. I configured the cipher suite list to only allow a certain list of ciphers (we still have TLS 1.0 clients but I want to restrict the ciphers they can use). Why does the client authenticate fine with the cipher suite list if I don't have VerifyClient set? That should indicate the cipher list is fine. With both olcTLSCipherSuite and olcTLSVerifyClient set I get: TLS: certdb config: configDir='/etc/openldap/cacerts' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11 error. TLS: skipping 'cacert.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'cacert-wheezy.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: loaded CA certificate file /etc/openldap/cacerts/f4033bb2.0 from CA certificate directory /etc/openldap/cacerts. TLS: loaded CA certificate file /etc/openldap/cacerts/a9b3780c.0 from CA certificate directory /etc/openldap/cacerts. TLS: certificate [CN=wheezy-test.esat.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE] is valid TLS: error: connect - force handshake failure: errno 0 - moznss error -12256 TLS: can't connect: TLS error -12256:SSL received a malformed Certificate Request handshake message.. ldap_err2string With olcTLSCipherSuite set but not olcTLSVerifyClient: TLS: certdb config: configDir='/etc/openldap/cacerts' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11 error. TLS: skipping 'cacert.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'cacert-wheezy.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: loaded CA certificate file /etc/openldap/cacerts/f4033bb2.0 from CA certificate directory /etc/openldap/cacerts. TLS: loaded CA certificate file /etc/openldap/cacerts/a9b3780c.0 from CA certificate directory /etc/openldap/cacerts. TLS: certificate [CN=wheezy-test.esat.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE] is valid TLS certificate verification: subject: CN=wheezy-test.esat.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE, issuer: CN=test ca,OU=ESAT,O=KU Leuven,L=Heverlee,ST=Leuven,C=BE, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_open_defconn: successful Without olcTLSCipherSuite but with olcTLSVerifyClient: TLS: certdb config: configDir='/etc/openldap/cacerts' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11 error. TLS: skipping 'cacert.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'cacert-wheezy.pem' - filename does not have expected format (certificate hash with numeric suffix) TLS: loaded CA certificate file /etc/openldap/cacerts/f4033bb2.0 from CA certificate directory /etc/openldap/cacerts. TLS: loaded CA certificate file /etc/openldap/cacerts/a9b3780c.0 from CA certificate directory /etc/openldap/cacerts. TLS: certificate [CN=wheezy-test.esat.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE] is valid TLS certificate verification: subject: CN=wheezy-test.esat.kuleuven.be,OU=ESAT,O=KU Leuven,ST=Leuven,C=BE, issuer: CN=test ca,OU=ESAT,O=KU Leuven,L=Heverlee,ST=Leuven,C=BE, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_open_defconn: successful So it looks like it's using the same cipher?? So why does moznss fail on the first setting? Regards, Rik
I tried the same reproducer as in comment 10, only with openssl as the crypto backend, and it works as well. (In reply to Rik Theys from comment #11) > Hi, > > Regarding comment 9: > > When I remove the olcTLSCipherSuite line and fall back to the default, it > seems to work. The olcTLSProtocolMin is an unknown parameter on the Debian > Wheezy version. > > Regarding comment 10: > > We have/had olcTLSVerifyClient set to allow but our clients don't send a > client certificate. Is your server on Debian Wheezy with openldap compiled > against gnutls? This is Fedora bugzilla, I'm testing on a Fedora machine. According to slapd-config(5), olcTLSProtocolMin is ignored when using gnutls. I can't help with that, sorry. > So it looks like it's using the same cipher?? As I already mentioned, I don't know how the cipher suites work. > So why does moznss fail on the first setting? No idea.