On 11 Mar 2020, at 14:29, Rob Crittenden via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
Alexander Bokovoy via FreeIPA-users wrote:
On ke, 11 maalis 2020, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On ke, 11 maalis 2020, Fraser Tweedale via FreeIPA-users wrote:
Makes me look at this a different way. Perhaps change the certstore to only return valid CA certs. That way they are stored if anyone ever wants them but they won't get pulled down for ipa-certupdate or ipaclilent-install.
Or to try the ipa-cacert-manage route, it was mostly the UI part for why I didn't do it. I wasn't sure if the best way would be to interactively show each cert and do a delete Y/N or what. Perhaps a delete with --expired-only to do the cleanup. I'm open to suggestions.
rob
I think it's fine to change ipa-certupdate so it skips expired / not-yet-valid certs.
IMO we should never automatically prune expired certs from the LDAP trust store, so that if customer needs to do time travel to fix an issue, the old CA certs will still be there and an ipa-certupdate will "restore" them to the various certificate DBs.
And for the same reason, I'd be hesitant to offer a UI to prune expired certs from the trust store.
I agree. So, we still need a ticket for ipa-certupdate to gain an explicit option to ignore expired certs.
IMHO it should be the default for certstore.get_ca_certs(). I opened https://pagure.io/freeipa/issue/8223 https://pagure.io/freeipa/issue/8223
I don't know of a case where we would want to fetch non-valid CA certificates, please update the ticket if you know of any.
Valid from which point of view? A system we run on? E.g. based on the local time setup?
Correct, local time.
Francois updated the issue to indicate that the expired CA first causes issues. I wonder if we should test sorting by expiration date instead.
rob _______________________________________________
Hi,
A quick update on this issue. The CA cert I mentioned initially has now expired.
The first thing that stopped working was Satellite, which could no longer connect to IPA.
Using “openssl s_client” to connect to the LDAP server in IPA also returned "verify error:num=10:certificate has expired”.
Both the old and the new certificate was present in /etc/pki/tls/cert.pem (symlinked to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem) on the Satellite server.
Removing the expired certificate and restarting the httpd and foreman-proxy services allowed Satellite to resume operations. And “openssl s_client” started returning "verify return:1”.
Further running ipa-certupdate on any client removed the expired cert from /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, however SSSD stopped working. When I ran ipa-certupdate shortly after the CA cert was renewed in February, both the new and the old certificate was kept.
When users logged in the following was logged in /var/log/secure: pam_sss(sshd:account): Access denied for user username: 6 (Permission denied)
Running "sssctl user-checks username” on the server returned "pam_acct_mgmt: Permission denied”.
The "sss_cache -E” command was not sufficient to fix the issue.The SSSD service and had to be stopped, then manually flush the cache (rm -f /var/lib/sss/db/*), and then start the SSSD service again.
Now "sssctl user-checks username” returned "pam_acct_mgmt: Success”, and the users we’re able to log on again.
As I mentioned ipa-certupdate was run in February as well, however the SSSD issues did not occur at this time.
Regards, Siggi