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
The cert still doesn't seem to be renewing, though. Here is the debug and catalina.out. 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