We are facing an issue in one of our openldap environments, while enabling secure queries via ldaps:// our integration environment keeps returning the following error to out ldapsearch command:

SSL3_READ_BYTES:sslv3 alert bad record mac

while the same command pointing to our production environment connects correctly and returns matching entries. Same query against integration environment over port 389 and ldap:// also works.

Both run under the following versions:

  • Red Hat Enterprise Linux Server release 6.2 (Santiago)
  • OpenLDAP: slapd 2.4.23
  • OpenSSL 1.0.0-fips

Each one has its own certificate, signed by the same CA.

In our integration environment:

/etc/openldap/slapd.d/cn\=config.ldif :

olcTLSCACertificateFile: /etc/openldap/certs/root_CA.pem
olcTLSCertificateFile: /etc/openldap/certs/openldapint.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/openldapint.key

And in the same file, production environment:

olcTLSCACertificateFile: /etc/openldap/certs/root_CA.pem
olcTLSCertificateFile: /etc/openldap/certs/openldapPRO.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/openldap.key

And we can check this problem doing the following:

$ openssl s_client -connect localhost:636 -showcerts -CApath /etc/openldap/cert/root_CA.pem
CONNECTED(00000003)
depth=1 L = (...), OU = (...), CN = (...)
verify error:num=19:self signed certificate in certificate chain
verify return:0
139866277001032:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1193:SSL alert number 20
139866277001032:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---

Any ideas on what's wrong, and how to configure our secure LDAPS:// for OpenLDAP?

Thanks!

SSL3_READ_BYTES:sslv3 alert bad record mac

From the sounds of it, its a bug with OpenSSL. See Debian Bug 212410 and Debian Bug 338006.

Here's a similar issue being for 1.0.0 being discussed on the OpenSSL mailing list: OpenSSL SSL_Accept Error.

There was an AES-NI bug that produced a similar message, but it was discovered in 1.0.1c and fixed in 1.0.1d (and it affected TLS 1.1 and TLS 12) (see the CHANGE LOG).

I think the standard recommendations probably applies: be sure you and the other endpoint are using the latest OpenSSL.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.