My Certificate doesn't work on all machines

Question

I installed Centos7 on my new brand server. I use LDAP as authentication. I deployed my certificate on all server and LDAPS is working with RHEL5, Debian or SOLARIS

On Centos7, I 've got problem with sssd That I didn't know before this install. The LDAP is working and I can do su - $user well. When I upgraded in LDAPS, I Lost this authentication. On my LDAP server I've got this error:

[30/oct./2014:16:32:05 +0100] DISCONNECT conn=735741 reason="Protocol Error" msg="The client sent a request to  Directory Server which did not decode  well as LDAP message : javax.net.ssl.SSLException: Received fatal alert: bad_certificate"

Why the the same certificate works on the other server and not on this one

Thanks for answer.

---

Thanks BillThor,

But the system seems do that for me as the the symbolic link with the hash return has been created. By the way I modified this line in the ldap.conf

TLS_CACERT /etc/openldap/cacerts/xxxxxx.0

I tested it with the ldapsearch -x -d3 command and I've got this error messages :

    attempting to connect: 
connect success
TLS: loaded CA certificate file /etc/openldap/cacerts/xxxxxx.0.
tls_write: want=157, written=157
.../...
certificate  is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure
TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
TLS: can't connect: TLS error -8157:Certificate extension not found..
ldap_err2string

That's strange because all my server accept this CA but not the new one under CENTOS7 Any idea where is coming from ?

---

Answer 1

I think this bit is probably the key:

certificate  is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure

My guess is that the server that refuses the cert might be configured not to accept SHA-1 based signatures. I'm no cryptographer, but of the other SSL issues that have come to my attention in recent times, I'm not thinking of others that seem to fit.

You should take my guess about the particulars with a grain of salt, but should keep in mind the possibility that the reason why this server is refusing your certificate is well founded, and that it's the servers which do accept the certificate which should have their configuration reviewed.

EDIT: There's more description of the problem, and a workaround here for ldapsearch: https://bugzilla.redhat.com/show_bug.cgi?id=895513.

Looks like the problem may be with MD5 rather than SHA-1 as I had guessed. It seems that as of ldapsearch 3.14:

Certificate signatures that make use of the MD5 hash algorithm will now
be rejected by default. Support for MD5 may be manually enabled (but is
discouraged) by setting the environment variable of
"NSS_HASH_ALG_SUPPORT=+MD5"
or by using the NSS_SetAlgorithmPolicy function. Note that SSL cipher
suites with "MD5" in their names are NOT disabled by this change; those
cipher suites use HMAC-MD5, not plain MD5, and are still considered safe.

Given that your error is on the server, you could probably address the problem on that system only.

If the issue is with MD5, I would recommend that you think very carefully before taking this approach. The attack on MD5 certificates is very much a practical one, and if you're not getting rid of your MD5 certificates, you should ask why you are running a CA at all.

http://www.win.tue.nl/hashclash/rogue-ca/

If this is about the newer issue with SHA-1, the attack is harder, and whether it is practical depends on the length of the CA's signing key.

Answer 2

Besides deploying the certificate, you may need to create a symbolic link for the certificate. The c_rehash utility is provided for this. You can also use a command openssl x509 -noout -hash -in vsignss.pem to get the hash value for the certificate. The symlinks have a .0 suffix.

Alternatively, you can add the certificate to your LDAP configuration. This could be /etc/ldap/ldap.conf. Older versions also had settings in pam_ldap.conf.

EDIT: The handshake error may be a result of disabling SSLv3 or otherwise restricting the available algorithms. I recently disabled SLLv3 due to the Poodle vulnerability. I included the commands I used to test connections at the end. In your case try a commands like:

openssl s_client -connect localhost:ldap
openssl s_client -quiet -connect localhost:ldap -ssl3
openssl s_client -quiet -connect localhost:ldap -tls1
openssl s_client -quiet -connect localhost:ldap -tls1_2

Answer 3

You did not indicate how you installed the CA cert file. When using RH or derivatives you could just use the info in man update-ca-trust, the tldr; version is:

1. copy the CA cert file to /etc/pki/ca-trust/source/anchors/
2. run update-ca-trust enable && update-ca-trust
3. profit!

update-ca-trust comes with the package ca-certificates which is in the base repository.

That should take care of nearly everything. In my experience just php is special and requires extra attention by specifying in /etc/openldap/ldap.conf (system wide) or $HOME/.ldaprc (just for one user):

TLS_CACERT /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

This TLS_CACERT path is what the update-ca-trust tool manages, by the way.

Answer 4

Folks, Thanks for all.

I found these links :

https://bugzilla.redhat.com/show_bug.cgi?id=895513

and this one :

http://www.unixmen.com/rhel-centos-6-4-ldap-md5-certificate-error-caused-by-nss-3-14-update/

I've got one problem for testing this solution, how to put this following line in GRUB2

systemd.setenv=NSS_HASH_ALG_SUPPORT=+MD5

So, I 've got the answer here : add systemd setenv in grub2

Thanks.