[Freeipa-users] (no subject)

[Jimmy]

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?


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