[Freeipa-users] (no subject)

[Rob Crittenden]

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