On 09/16/2016 04:22 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> hi, >> >> >> On Fri, Sep 16, 2016 at 10:34 AM, Martin Basti <mba...@redhat.com >> <mailto:mba...@redhat.com>> wrote: >> >> >> >> On 16.09.2016 09:38, Natxo Asenjo wrote: >>> hi, >>> >>> >>> On Thu, Sep 15, 2016 at 1:03 PM, Natxo Asenjo >>> <natxo.asenjo@gmail.c <mailto:natxo.ase...@gmail.com> >>> >>> On Thu, Sep 15, 2016 at 12:49 PM, Martin Basti >>> <mba...@redhat.com <mailto:mba...@redhat.com>> wrote: >>> >>> >>> >>> On 15.09.2016 12:44, Natxo Asenjo wrote: >>>> hi, >>>> >>>> On Thu, Sep 15, 2016 at 12:33 PM, Martin Basti >>>> <mba...@redhat.com <mailto:mba...@redhat.com>> wrote: >>>> >>>> >>>> Hello, >>>> >>>> usually the most information can be found here >>>> /var/log/pki/pki-tomcat/ca/debug >>>> >>>> >>>> mmm, in this centos 6.8 system that does not exist: >>>> >>>> # ls -l /var/log/pki/pki-tomcat/ca/debug >>>> ls: cannot access /var/log/pki/pki-tomcat/ca/debug: No >>>> such file or directory >>>> >>>> >>>> I do have a /var/log/pki-ca/debug >>>> >>>> >>> Does it contain any information related to your issue? >>> >>> >>> I have tried renewing the certificate: >>> >>> ipa-getcert resubmit -i 20121107212513 >>> >>> >>> If I grep that file for that request id I find nothing recent, >>> just in the ipaserver installation log >>> >>> # cd /var/log >>> # grep -ri 20121107212513 *.log >>> ipaserver-install.log:2012-11-07T21:25:13Z DEBUG stdout=New >>> tracking request "20121107212513" added. >>> >>> # grep -ri 20121107212513 pki-ca >>> # >>> >>> >>> Any clues? >>> >>> >>> -- >>> Groeten, >>> natxo >> >> >> Sorry, I'm quite lost here, maybe somebody from dogtag can help what >> might be reason of those CA errors >> >> >> >> do I need to ask in the dogtag list? > > You won't find any errors on this in the dogtag logs because it isn't > getting that far. > > The 3 certs you list are the ones that are renewed via the IPA API (as > opposed to the subsystem certs renewed directly by dogtag). I think the > failures are all related. I had someone else report the CSR decoding > failure and he just restarted IPA and that fixes things for him though > it was a rather unsatisfying fix. > > What I'd do is this. Assuming each step works, move onto the next. > > 1. ipa cert-show 1 > > The serial # picked more or less at random, we're testing connectivity > and that the CA is up and operational. > > 2. I assume that getcert list | grep expire shows all certs currently > valid? The IPA service certs expire in a month, how about the CA > subsystem certs? > > 3. Is this the same server having problems talking to the CA due to the > other NSS errors? If so what I'd do is restart httpd then immediately > use ipa-getcert to resubmit the requests to try to get into that few > minute window.
The error log from thread [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format." looks like it. > > If this is the same box you already have debugging enabled so seeing > what that shows might be helpful. > > rob > -- 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