[Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.
Petr Vobornik
pvoborni at redhat.com
Fri Sep 16 14:41:08 UTC 2016
On 09/16/2016 09:39 AM, Natxo Asenjo wrote:
> hi,
>
>
> Any clues?
>
output of
$ cat error_log | grep INFO -A 1 | cut -c -120
shows that first cert-show was successful. It was followed by cert-request.
cert-request internally called
- host-show
- cert_show(1) success
- cert_show(162) success
- ipaserver.plugins.dogtag.ra.get_certificate()
https_request 'https://xx.xxx.xxx.xx:443/ca/agent/ca/displayBySerial'
- cert_revoke(162, recvocation_reason=4)
- cert_show(162) success
- cert_show(1) - success
- ipaserver.plugins.dogtag.ra.revoke_certificate()
- https_request 'https://xx.xxx.xxx.xx:443/ca/agent/ca/doRevoke'
ends with:
NetworkError
[Thu Sep 15 13:08:23 2016] [error] ipa: DEBUG: response: NetworkError:
cannot connect to 'https://xx.xxx.xxx.xx:443/ca/agent/ca/doRevoke':
(SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.
After it every other communication with CA ends with the issue in subject:
cert_show(u'15'): NetworkError
[Thu Sep 15 13:08:26 2016] [error] ipa: DEBUG: response: NetworkError:
cannot connect to
'https://xx.xxx.xxx.xxl:443/ca/agent/ca/displayBySerial':
(SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
unsupported format.
So the main issue is "NSS could not shutdown." Investigation of that is
beyond me.
Maybe a workaround can be do first revoke existing cert for the host and
then request a new one - which might trigger a different sequence of
calls and hopefully not reproduce the issue. But the issue will be still
present.
--
Petr Vobornik
More information about the Freeipa-users
mailing list