On 04/26/2016 06:00 PM, Bret Wortman wrote:
> # getcert list | grep expires
>      expires: 2018-04-02 13:04:51 UTC
>      expires: 2018-04-02 13:04:31 UTC
>      expires: unknown
>      expires: 2016-04-17 18:19:19 UTC
>      expires: 2016-04-17 18:19:18 UTC
>      expires: 2016-04-17 18:19:19 UTC
>      expires: 2016-04-01 20:16:39 UTC
>      expires: 2016-04-17 18:19:35 UTC
>      expires: 2016-03-11 13:04:29 UTC
>      expires: unknown
> #
> 
> So some got updated and most didn't. Is there a recommended way to update 
> these 
> all? The system is still backdated to 3 April (ntpd disabled) at this point.

It's usually good to start renewing(when it doesn't happen automatically
from some reason) with the cert which is about to expired first, i.e.
the one with "2016-03-11 13:04:29"

The process is:
- move date before the cert is about to expired
- leave it up to certmonger or manually force resubmit by `getcert
resubmit -i $REQUEST_ID`, where request ID is in `getcert list` output.

I'm little worried about the fact that CA cert was renewed at date which
is after expiration of the other certs.

Also the `expires: unknown` doesn't look good. Check `getcert list`
output for errors related to the cert.


> 
> 
> Bret
> 
> 
> On 04/26/2016 11:46 AM, Petr Vobornik wrote:
>> On 04/26/2016 03:26 PM, Bret Wortman wrote:
>>> On our non-CA IPA server, this is happening, in case it's related and 
>>> illustrative:
>>>
>>> # ipa host-del zw113.private.net
>>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
>>> certificate/key database is in an old, unsupported format.
>>> #
>> I would start with checking on all IPA servers if and what certificates
>> are expired:
>>    # getcert list
>> or short version to check if there are any:
>>    # getcert list | grep expires
>>
>> When CA cert is renewed, it is not automatically transfered to clients.
>> There one must run:
>>    # ipa-certupdate
>>
>>> On 04/26/2016 09:24 AM, Bret Wortman wrote:
>>>> I rolled the date on the IPA server in question back to April 1 and ran
>>>> "ipa-cacert-manage renew", which said it completed successfully. I rolled 
>>>> the
>>>> date back to current and tried restarting ipa using ipactl stop && ipactl
>>>> start, but no joy. No more ca renewal errors, but right after the pause I 
>>>> see
>>>> this in /var/log/messages:
>>>>
>>>> systemd: kadmin.service: main process exited, code=exited,
>>>> status=2/INVALIDARGUMENT
>>>> systemd: Unit kadmin.service entered failed state.
>>>> systemd: kadmin.service failed.
>>>>
>>>> I rebooted the server just in case, and it's still getting stuck at the 
>>>> same
>>>> place. ipa-otpd doesn't get around to starting.
>>>>
>>>>
>>>> Bret
>>>>
>>>> After the several-minutes-long pause after ipactl start outputs "Starting
>>>> pki-tomcatd Service", I get the
>>>>
>>>> On 04/26/2016 08:14 AM, Bret Wortman wrote:
>>>>> I have an IPA server on a private network which has apparently run into
>>>>> certificate issues this morning. It's been running without issue for 
>>>>> quite a
>>>>> while, and is on 4.1.4-1 on fedora 21.
>>>>>
>>>>> This morning, the gui started giving:
>>>>>
>>>>> IPA Error 907: NetworkError with description "cannot connect to
>>>>> 'https://zsipa.private.net:443/ca/agent/ca/displayBySerial':
>>>>> (SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as 
>>>>> expired."
>>>>>
>>>>> I dug into the logs and after trying to restart ipa using ipactl, there 
>>>>> was a
>>>>> length pause, then:
>>>>>
>>>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
>>>>> certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in
>>>>> database "/etc/httpd/alias" is no longer valid.
>>>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
>>>>> certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS
>>>>> Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer 
>>>>> valid.
>>>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available.
>>>>> named-pkcs11[3437]: client 192.168.208.205#57832: update
>>>>> '208.168.192.in-addr.arpa/IN' denied
>>>>>
>>>>> and then things start shutting down. I can't start ipa at all using 
>>>>> ipactl.
>>>>>
>>>>> So at present, our DNS is down. Authentication should work for a while, 
>>>>> but
>>>>> I'd like to get this working again as quickly as possible. Any ideas? I 
>>>>> deal
>>>>> with certificates so infrequently (like only when something like this
>>>>> happens) that I'm not sure where to start.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> -- 
>>>>> *Bret Wortman*
>>>>> /Coming soon to Kickstarter.../
>>>>> <http://wrapbuddies.co/>
>>>>> http://wrapbuddies.co/
>>>>>
> 


-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to