After a recent update to the latest RHEL 6.4, an issue arose that caused LDAP to stop using our MD5 signed certificate. This was due to the nss-3.14.0 update that now deems MD5 as un-secure. This change caused authentication of users using LDAP to fail. If the account had a local password (such as root), they were able to login.
Since creating/updating the MD5 certificate was not an immediate solution, there had to find a way to use the current certificate until a new one was generated. Here are a few of the workarounds.
Option 1
The first option involves modifying each kernel line in /etc/grub.conf and adding support for MD5 as well as creating a file in /etc/profile.d exporting this variable. In our situation this option did not work, but for others on the internet it worked.
Add in /etc/grub.conf to the end of kernel lines:
systemd.setenv=NSS_HASH_ALG_SUPPORT=+MD5
Create /etc/profile.d/nss.sh:
export NSS_HASH_ALG_SUPPORT=+MD5
Reboot the server.
Option 2
The second option adds the export option to /etc/sysconfig/init. This option worked for allowing users to connect via SSH, but it did not allow authentication when accessing via a console, like open console option in vSphere.
Add to /etc/sysconfig/init
export NSS_HASH_ALG_SUPPORT=+MD5
Reboot the server.
Option 3
The third option involves downgrading nss packages to 3.13 and adding an exclusion in /etc/yum.conf to not allow an update to nss 3.14 or higher. This was the option that worked for our situation.
You will need to downgrade nss, nss-tools, nss-sysinit and nss-util:
$ sudo yum downgrade nss nss-tools nss-sysinit nss-util
Next open /etc/yum.conf and add/change:
exclude=nss*
Reboot the server.
All three options are only temporary and eventually an update to any modules that require nss .14 or higher will not be able to be applied until a new certificate is created.
