On 03/20/2012 01:16 PM, Jimmy wrote:
I was able to do this:
/usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif
/usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif
ok - let's make sure this step worked - any errors in /var/log/dirsrv/slapd-PKI-IPA/errors?


The cert still doesn't seem to be renewing, though. Here is the debug
and catalina.out.
What about /var/log/dirsrv/slapd-PKI-IPA/access?

http://fpaste.org/k0Lz/
http://fpaste.org/UUnE/

  ipa-getcert list shows this for a couple certs in question:

Request ID '20110913154314':
        status: MONITORING
        ca-error: Error setting up ccache for local "host" service
using default keytab.
        stuck: no
        key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
        certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=ABC.XYZ
        subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ
        expires: 2012-03-11 15:43:13 UTC
        eku: id-kp-serverAuth
        command:
        track: yes
        auto-renew: yes
Request ID '20110913154337':
        status: MONITORING
        ca-error: Error setting up ccache for local "host" service
using default keytab.
        stuck: no
        key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
        certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=ABC.XYZ
        subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ
        expires: 2012-03-11 15:43:37 UTC
        eku: id-kp-serverAuth
        command:
        track: yes
        auto-renew: yes




On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittenden<rcrit...@redhat.com>  wrote:
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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to