1

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!

1 Answer 1

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .