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<g17ji...@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<rcrit...@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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
