Petr Vobornik via FreeIPA-devel wrote:
> On Wed, Aug 2, 2017 at 3:30 AM, Fraser Tweedale <ftwee...@redhat.com> wrote:
>> Hi devs,
>> This is at least the second time recently that people needing to
>> renew service certificates used ``ipa-cacert-manage renew`` (the
>> wrong command) and either didn't solve the problem or got into a
>> deeper mess.
>> Clearly we have a usability problem here.
>> The ipa-cacert-manage(1) man page is clear, but perhaps could use a
>> prominent statement that it doesn't renew service certs and if
>> that's all the user needs to do, to use `getcert resubmit` instead.
> Right, I think that a lot of people don't understand certificates well
> and so they don't distinguish CA cert and other cert. So when they see
> a howto for "CA certificate renewal" they understand "certificate
> From that perspective another possible culprit is also page:
>> But I think better would be to enhance `ipa-cacert-manage renew` to
>> inspect the current CA certificate and if it has, say, more than 75%
>> of its validity period still to go, to PROMPT the user to confirm
>> that renewing the *CA* certificate is really what they wanted to do.
>> What do others think of this idea?
> I like the idea.
Honestly, I'd be even harsher. IMHO this is one of those times that
Are you sure? (yes/NO)
Are you really sure? (yes/NO)
Really, you want to renew the CA certificate and not some other
certificate? This is not something to be done lightly? (yes/NO)
<insert another 72 questions here>
>> On Tue, Aug 01, 2017 at 05:22:53PM +0200, Florence Blanc-Renaud via
>> FreeIPA-users wrote:
>>> On 08/01/2017 03:50 PM, Jason B. Nance via FreeIPA-users wrote:
>>>> Hello everyone,
>>>> I'm running FreeIPA 4.4 (as shipped with current CentOS 7). I had a
>>>> series of unfortunate events which resulted in the entire cluster being
>>>> offline for a matter of a couple weeks during which the certificate in
>>>> /etc/httpd/alias expired. I rolled back the clocks on all of the servers
>>>> in the cluster and started them successfully, however, the certificates in
>>>> /etc/httpd/alias did not get renewed. Is there a process that
>>>> automatically handles this or was I supposed to be maintaining that?
>>>> Additionally, based on:
>>>> ...I ran "ipa-cacert-manage renew" on my CA in a hope that that would
>>>> trigger renewals across the boards, but now it appears that only the CA
>>>> was updated as none of the server certificates were re-issued and are now
>>>> all untrusted (I can't do "kinit admin" any longer as my realm is now
>>>> down). Is there any chance of rolling that back or issuing new certs to
>>>> get things going again?
>>> ipa-cacert-manage will only renew IPA CA certificate, not the LDAP or HTTP
>>> server certificates.
>>> When IPA is using an embedded CA, the LDAP and HTTP server certificates
>>> should be automatically renewed thanks to certmonger. If the automatic
>>> renewal did not happen, you can check:
>>> - if the certificates are indeed tracked by certmonger
>>> sudo getcert list -n Server-Cert
>>> The tool should output one cert for HTTP (in /etc/httpd/alias) and one for
>>> LDAP (in /etc/dirsrv/slapd-DOM...). If the certs are not tracked, you need
>>> to use getcert start-tracking to track them.
>>> - if they are tracked but not renewed, check the journal for certmonger
>>> messages. Certmonger should log a message when a certificate is nearing its
>>> expiration, and another message when the renewal succeeded.
>>> When the certificates are expired, the method is to stop ntpd, go back in
>>> time to a date where the certs were still valid, then manually trigger the
>>> renewal using getcert resubmit -i <ID>. In case of errors, examine the
>>> journal logs and try to fix the issue, then relaunch getcert resubmit. Once
>>> the renewal succeeds, getcert list shows the cert status as MONITORING and
>>> you can restart ntpd.
>>> This blog  provides a few examples of issues and their resolution
>>>> If I have to start over, that is certainly an option. I'm just trying to
>>>> get a better understanding of what I should have been doing to avoid this
>>>> situation in the first place.
>>>> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
>>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>>> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
FreeIPA-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org