[Freeipa-users] (no subject)

Tue Mar 20 17:41:00 UTC 2012

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
>>>>>>>>>
>>>>>>
>>>>
>>