[Freeipa-users] (no subject)

Jimmy g17jimmy at gmail.com
Tue Mar 20 19:16:48 UTC 2012 

I was able to do this:
/usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif
/usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif

The cert still doesn't seem to be renewing, though. Here is the debug
and catalina.out.

http://fpaste.org/k0Lz/
http://fpaste.org/UUnE/

 ipa-getcert list shows this for a couple certs in question:

Request ID '20110913154314':
       status: MONITORING
       ca-error: Error setting up ccache for local "host" service
using default keytab.
       stuck: no
       key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
       certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
       CA: IPA
       issuer: CN=Certificate Authority,O=ABC.XYZ
       subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ
       expires: 2012-03-11 15:43:13 UTC
       eku: id-kp-serverAuth
       command:
       track: yes
       auto-renew: yes
Request ID '20110913154337':
       status: MONITORING
       ca-error: Error setting up ccache for local "host" service
using default keytab.
       stuck: no
       key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
       certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
       CA: IPA
       issuer: CN=Certificate Authority,O=ABC.XYZ
       subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ
       expires: 2012-03-11 15:43:37 UTC
       eku: id-kp-serverAuth
       command:
       track: yes
       auto-renew: yes




On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittenden <rcritten at redhat.com> wrote:
> Jimmy wrote:
>>
>> When I try to export the db I get this:
>>
>>  /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a
>> /dbexport/ipaca-output.ldif
>> Exported ldif file: /dbexport/ipaca-output.ldif
>> [03/Mar/2012:17:27:25 +0000] - ERROR: Could not find backend 'ipaca']
>
>
> The CA uses a different instance of 389-ds. You need to run the scripts
> specific to that instance. dogtag sets things up slightly differently, you
> want something like:
>
> /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a
> /dbexport/ipaca-output.ldif
>
>
>> When I start IPA as it is now these are the logs I get:
>>
>> debug- http://fpaste.org/ItuZ/
>> catalina.out- http://fpaste.org/tSyQ/
>
>
> Yes, as I suspected it isn't finding any of its data which is why the
> certificate renewal is failing.
>
> rob
>
>
>>
>> -Jimmy
>>
>> On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden<rcritten at redhat.com>
>>  wrote:
>>>
>>> Jimmy wrote:
>>>>
>>>>
>>>> This is all I see in the /var/log/httpd/error_log file. This issue has
>>>> become critical. The server has been down a week and I have no idea
>>>> why certmonger broke and don't seem to have any indication of how to
>>>> fix it. What would be the best route besides chasing down this
>>>> certmonger issue? Could I export all of my configuration/users/etc,
>>>> install a completely new IPA and import my config?
>>>>
>>>> [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget
>>>> 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial'
>>>> [Sat Mar 03 00:05:28 2012] [error] ipa: INFO:
>>>> host/csp-idm.pdh.csp at PDH.CSP:
>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1
>>>>
>>>>
>>>> UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q
>>>>
>>>>
>>>> Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH
>>>>
>>>>
>>>> hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM
>>>>
>>>>
>>>> BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW
>>>>
>>>>
>>>> RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY
>>>>
>>>>
>>>> JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh
>>>>
>>>>
>>>> 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q
>>>>
>>>>
>>>> IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=',
>>>> principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C
>>>> ertificateOperationError
>>>
>>>
>>>
>>> I think your CA is still not up and running.
>>>
>>> Things to check:
>>>
>>> /var/log/pki-ca/catalina.out to be see if there are start up errors. The
>>> debug log in the same directory may contain information as well. If you
>>> are
>>> seeing a bunch of error 32's it means your db is still corrupted.
>>>
>>> The output of ipa-getcert list. This will tell you what certmonger thinks
>>> is
>>> wrong.
>>>
>>> Did you repair the ipaca backend in PKI-IPA? It is different than
>>> userRoot.
>>>
>>>
>>> rob
>>>
>>>>
>>>>
>>>> On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden<rcritten at redhat.com>
>>>>  wrote:
>>>>>
>>>>>
>>>>> Jimmy wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> I actually shut down IPA to do the export and restarted after I
>>>>>> imported.
>>>>>>
>>>>>> certutil -L -d /etc/httpd/alias
>>>>>> Certificate Nickname                                         Trust
>>>>>> Attributes
>>>>>>
>>>>>>  SSL,S/MIME,JAR/XPI
>>>>>> Server-Cert                                                  u,u,u
>>>>>> ABC.XYZIPA CA                                               CT,C,C
>>>>>> ipaCert                                                      u,u,u
>>>>>> Signing-Cert                                                 u,u,u
>>>>>>
>>>>>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f
>>>>>> /etc/httpd/alias/pwdfile.txt
>>>>>> certutil: certificate is valid
>>>>>>
>>>>>> How's that look?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That's what it's supposed to look like. Is Apache logging a failure or
>>>>> maybe
>>>>> that is coming from dogtag through Apache...
>>>>>
>>>>>
>>>>> rob
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden<rcritten at redhat.com>
>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jimmy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Looks pretty similar to what we've been seeing. The invalid
>>>>>>> credentials
>>>>>>> means that dogtag can't validate RA agent cert. This was due to the
>>>>>>> corrupted database. You'll need to restart the pki-cad process once
>>>>>>> the
>>>>>>> LDAP
>>>>>>> backend is fixed.
>>>>>>>
>>>>>>> The trust issues are stranger. To show the certs in those databases:
>>>>>>>
>>>>>>> # certutil -L -d /etc/httpd/alias
>>>>>>>
>>>>>>> To verify that the cert in there now has all the CA certs it needs:
>>>>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f
>>>>>>> /etc/httpd/alias/pwdfile.txt
>>>>>>>
>>>>>>> rob
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy<g17jimmy at gmail.com>
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot
>>>>>>>>> and
>>>>>>>>> that went smoothly but now I see this in /var/log/pki-ca/system:
>>>>>>>>>
>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3]
>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32);
>>>>>>>>> matchedDN
>>>>>>>>>  = o=ipaca
>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3]
>>>>>>>>> Null
>>>>>>>>> response control
>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3]
>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32);
>>>>>>>>> matchedDN
>>>>>>>>>  = o=ipaca
>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3]
>>>>>>>>> Null
>>>>>>>>> response control
>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3]
>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32);
>>>>>>>>> matchedDN
>>>>>>>>>  = o=ipaca
>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3]
>>>>>>>>> Null
>>>>>>>>> response control
>>>>>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3]
>>>>>>>>> [3]
>>>>>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in
>>>>>>>>> the
>>>>>>>>> internaldb. The internaldb could be down. Error LDAP operation
>>>>>>>>> failure
>>>>>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
>>>>>>>>> netscape.ldap.LDAPE
>>>>>>>>> xception: error result (32); matchedDN = o=ipaca
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> catalina.out -- http://fpaste.org/oRQd/
>>>>>>>>>
>>>>>>>>> ca-debug -- http://fpaste.org/zzFL/
>>>>>>>>>
>>>>>>>>> Any ideas?
>>>>>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob
>>>>>>>>> Crittenden<rcritten at redhat.com>
>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jimmy wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The ca_audit problem was caused by me accidentally moving the
>>>>>>>>>>> directory to a backup location. I was cleaning up the logs to
>>>>>>>>>>> make
>>>>>>>>>>> reading easier. When I moved the directory back that issue went
>>>>>>>>>>> away.
>>>>>>>>>>> No changes were made in the NSS database(s) or any other internal
>>>>>>>>>>> workings of IPA. This system is used for very basic user
>>>>>>>>>>> authentication, DNS, etc.
>>>>>>>>>>>
>>>>>>>>>>> I can do the ldif export/import for dogtag. Just from comparing
>>>>>>>>>>> everything, it looks like the dogtag db is in
>>>>>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The ipaca db
>>>>>>>>>>
>>>>>>>>>> rob
>>>>>>>>>>
>>>>>>>
>>>>>
>>>
>

More information about the Freeipa-users mailing list