I guess this is a feature rather than a bug but I'd appreciate a workaround. At $WORKPLACE I set up an LDAP-based single-sign-on environment back in the days of RHEL-4. Since then the company has been taken over and we're in the process of migrating everyone over to Active Directory but we still have a bunch of engineering systems on the old LDAP system. One of these is my Fedora desktop box, which I've just updated to Fedora 18. I'm finding that I cannot authenticate to the LDAP server because sssd doesn't like the certificate: sssd[be[default]]: Could not start TLS encryption. TLS error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure. The certificate signature algorithm is: md5WithRSAEncryption It claims to be 1024 bit RSA. Is that not considered secure these days? I recall starting to see this message appear whilst I was on Fedora 17 but it never seemed to cause me any problems, which I now suspect was because my credentials were cached prior to the signature being considered not secure. Bearing that in mind, I was able to log in by priming the cache as root: # sss_seed --domain default --username phowarth However, it doesn't solve the underlying problem of being able to use the LDAP server for authentication, nor can anybody else log in to my box as their credentials aren't cached. I've tried setting "ldap_tls_reqcert = never" in /etc/sssd/sssd.conf but that didn't help. Is there any workaround I can use to let sssd use my existing certificates, or am I going to have to try generating new certificates for all of my legacy infrastructure?
I now have a better workaround but anyone else struggling with this might not have this option. I have created a new replica of the LDAP database on an EL-6 system and generated a new CA and server certificate on that system, which now uses a signature algorithm of sha1WithRSAEncryption with 2048-bit RSA. I've pointed my Fedora desktop to that new LDAP server and NSS/sssd seem to be happy with it. I now have to decide whether to try rolling out the new CA to all of the legacy clients so that I can update the certificates on the existing LDAP servers.
Given that ldapsearch from openldap-clients also refuses to connect to my legacy servers via ldaps://, I suspected that this was an NSS issue rather than an sssd one. Sure enough, I found in the release notes for 3.14 that: 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. Setting this environment variable got ldapsearch working again. Given that NSS does not appear to have any site-wide configuration file, I now need to try to figure out how to get this environment variable set early enough in the boot process to affect all processes. That would save me having to touch any of my existing infrastructure.
(In reply to comment #2) > Given that NSS does not appear to have any site-wide configuration file, I > now need to try to figure out how to get this environment variable set early > enough in the boot process to affect all processes. That would save me > having to touch any of my existing infrastructure. I'm going with the following: First, to set the environment for system daemons, add "systemd.setenv=NSS_HASH_ALG_SUPPORT=+MD5" to all "linux" lines in /boot/grub2/grub.cfg and the GRUB_CMDLINE_LINUX entry in /etc/default/grub. Second, to set the environment for user sessions, create /etc/profile.d/nss.sh containing: # /etc/profile.d/nss.sh - workaround for http://bugzilla.redhat.com/895513 export NSS_HASH_ALG_SUPPORT=+MD5
(In reply to comment #3) > (In reply to comment #2) > > Given that NSS does not appear to have any site-wide configuration file, I > > now need to try to figure out how to get this environment variable set early > > enough in the boot process to affect all processes. That would save me > > having to touch any of my existing infrastructure. > > I'm going with the following: > > First, to set the environment for system daemons, add > "systemd.setenv=NSS_HASH_ALG_SUPPORT=+MD5" to all "linux" lines in > /boot/grub2/grub.cfg and the GRUB_CMDLINE_LINUX entry in /etc/default/grub. > > Second, to set the environment for user sessions, create > /etc/profile.d/nss.sh containing: > > # /etc/profile.d/nss.sh - workaround for http://bugzilla.redhat.com/895513 > > export NSS_HASH_ALG_SUPPORT=+MD5 Thanks for the solution, but wouldn;t it be easier to rekey the other server certificate ?
Not being particularly well versed in SSL, I didn't know if that would work. The original CA certificate I had was also MD5-signed, and I don't know if that would have any impact either, or if that could be regenerated with a new key without breaking any existing setup. I was particularly anxious not to break any existing system.
(In reply to comment #5) > Not being particularly well versed in SSL, I didn't know if that would work. > The original CA certificate I had was also MD5-signed, and I don't know if > that would have any impact either, or if that could be regenerated with a > new key without breaking any existing setup. I was particularly anxious not > to break any existing system. Ah good reason, NSS would probably refuse to trust your CA. Now all that said it seem this is not actually a bug in sssd in the end, should we close it ?
(In reply to comment #6) > (In reply to comment #5) > Now all that said it seem this is not actually a bug in sssd in the end, > should we close it ? Fine by me. At least it's documented in this ticket now, which will hopefully show up in a search if anyone else has a similar issue.
If this isn't a bug against "sssd" it should still be considered a bug against the distribution or the "nss" package. In a professional environment, this means any machine that recently upgraded from nss-3.13.* to nss-3.14 now cannot contact an LDAP server using an "insecure" certificate. If the administrator of those systems isn't able to change the LDAP server certificate in a reasonable amount of time, their users cannot authenticate and processes that rely on LDAP resolution cannot run. A workaround in business environments is to downgrade nss back to a 3.13 version.
(In reply to comment #8) > If this isn't a bug against "sssd" it should still be considered a bug > against the distribution or the "nss" package. > > In a professional environment, this means any machine that recently upgraded > from nss-3.13.* to nss-3.14 now cannot contact an LDAP server using an > "insecure" certificate. If the administrator of those systems isn't able to > change the LDAP server certificate in a reasonable amount of time, their > users cannot authenticate and processes that rely on LDAP resolution cannot > run. > > A workaround in business environments is to downgrade nss back to a 3.13 > version. See comment #2, this seems to be a deliberate upstream change. Anyway, I'm CC-ing the NSS maintainer in case he's got something to add.
I'm just surprised to find a change like this in a minor update (from the distribution perspective). I would expect this to be on a major update that requires interaction since it has potential to cause outages for RHEL customers.
(In reply to comment #10) > I'm just surprised to find a change like this in a minor update (from the > distribution perspective). I would expect this to be on a major update that > requires interaction since it has potential to cause outages for RHEL > customers. Bryan is correct. This is, in fact, causing outages for RHEL customers. We are unable to upgrade our certificates due to other legacy requirements that will likely persist for 12 months or more, and the nss 3.14 packages break previous functionality. Neither the NSS_HASH_ALG_SUPPORT=+MD5 or the NSS_ALLOW_WEAK_SIGNATURE_ALG=1 variables work for me.
(In reply to PJ from comment #11) > (In reply to comment #10) > > I'm just surprised to find a change like this in a minor update (from the > > distribution perspective). I would expect this to be on a major update that > > requires interaction since it has potential to cause outages for RHEL > > customers. > > Bryan is correct. This is, in fact, causing outages for RHEL customers. > > We are unable to upgrade our certificates due to other legacy requirements > that will likely persist for 12 months or more, and the nss 3.14 packages > break previous functionality. > > Neither the NSS_HASH_ALG_SUPPORT=+MD5 or the NSS_ALLOW_WEAK_SIGNATURE_ALG=1 > variables work for me. On EL-6, I had some success appending this to /etc/sysconfig/init: # http://bugzilla.redhat.com/895513 export NSS_HASH_ALG_SUPPORT=+MD5 as a replacement for using systemd.setenv on the kernel command line. It was at least sufficient for sssd to talk to my LDAP server.
To get sssd talking to your LDAP server (with the MD5 signed certificate) immediately, you can do: /bin/systemctl set-environment NSS_HASH_ALG_SUPPORT=+MD5 /bin/systemctl restart sssd.service