[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