This does raise a question as to why we don't provide a system nssdb. I think we should. I wonder if libnss or libnss3-tools could ship ca-certificates hook to provide a system nssdb certificate store.
If we are changing backends, and certs were provided for the nss backend, imho we should automatically convert them and keep them active for the openssl backend. However unlikely it is that somebody made nss-based p11_child work.
In nss, we do set minimum TLS version TLSv1.2 but we do not enforce 112 bits of security like we do with OpenSSL. Specifically that is 2k RSA minimum key size, nor prohibit SHA1/MD5 cert hashes, and any cipher suites that use RC4. These changes in minimum requirements do not affect p11_child, but would affect sssd itself when talking over ldaps. I would be worried that an LDAP server has a lowish sized key in their cert, and suddenly an upgrade of sssd, once caches expire, prevent logins.
This does raise a question as to why we don't provide a system nssdb. I think we should. I wonder if libnss or libnss3-tools could ship ca-certificates hook to provide a system nssdb certificate store.
If we are changing backends, and certs were provided for the nss backend, imho we should automatically convert them and keep them active for the openssl backend. However unlikely it is that somebody made nss-based p11_child work.
In nss, we do set minimum TLS version TLSv1.2 but we do not enforce 112 bits of security like we do with OpenSSL. Specifically that is 2k RSA minimum key size, nor prohibit SHA1/MD5 cert hashes, and any cipher suites that use RC4. These changes in minimum requirements do not affect p11_child, but would affect sssd itself when talking over ldaps. I would be worried that an LDAP server has a lowish sized key in their cert, and suddenly an upgrade of sssd, once caches expire, prevent logins.