CentOS 6.4: NSS, MD5 Certificates, and Authentication Problems

CentOS just released 6.4, so I decided to update the office server and as it was the end of the day, left it at that. Bad form on my end as I come in the next day to find I’m unable to connect to the samba server. Checking the logs I see samba is unable to connect to LDAP via TLS. I also quickly discover that the server itself is unable to get user information. First guess was to check the ldap server, but its running fine.

Second guess is to try ldapsearch from the office server and I get my first hint. Ldapsearch was not accepting my Certificate Authority and was giving a bad signature algorithm error. Researching that lead me to the following bug report:¬†Unable to authenticate to legacy LDAP server due to “not secure” certificate signature.

It becomes clear that due to the decision at Mozilla, who develop the NSS(Network Security Services) library to stop accepting MD5 hashes is the root issue. I then set out to downgrade NSS to pre 6.4 release. The following packages were the ones I downgraded to get my system working again: nss nss-sysinit nss-tools nss-util nss-pam-ldapd mod_nss.

Now some may ask why not just upgrade your certificates to a newer and thus more secure signing algorithm? Well to anyone who has ever worked with OpenSSL and creating certs for a multitude of servers, its not a trivial task. I’ll put it on my todo list, but for now its at the bottom.

Thanks to following blog post by Matt Micene that was the break in this case.

Advertisements

OpenSSL: Request Certificate Distinguished Name Mismatch Solved

I’m not sure if its a bug or a feature but something I ran into when signing a certificate request with our self signed certificate authority. The new system is running CentOS 6 and when I tried to sign the request, it would fail saying the state name didn’t match. It prints them both out and as far as I can tell, they are the same. But something that bothered me gave me a clue. It would print out Distinguished Name like so:

stateOrProvinceName :ASN.1 12:’Texas’

That ASN part made me think and this bug post gave me an idea. As I didnt want to go playing with the policy setting, I read through the openssl.cnf file for more details and I came upon the string_match setting. My CA had been created using the nombstr setting while in CentOS 6, it was set to utf8only. Editing openssl.cnf on the new system and creating a new request fixed the problem and now the DN looks like so:

stateOrProvinceName¬†¬† :PRINTABLE:’Texas’

So just be aware of this setting