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<rcrit...@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....@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....@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<rcrit...@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<rcrit...@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<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

Reply via email to