On 11 Mar 2020, at 14:29, Rob Crittenden via FreeIPA-users
<freeipa-users(a)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