On 08/07/2014 05:27 PM, Lucas Yamanishi wrote: > On 08/07/2014 04:48 PM, Rob Crittenden wrote: >> Lucas Yamanishi wrote: >>> On 08/07/2014 01:25 PM, Rob Crittenden wrote: >>>> Lucas Yamanishi wrote: >>>>> Hello, I'm a bit of a pickle with the PKI system. I have three >>>>> replicas, but only one contains the CA. I realize how poor a decision >>>>> it was to do that. I plan to create more complete replicas, but right >>>>> now I can't even create a replica file, much less a full replica. >>>>> >>>>> The problem started when the CA subsystem certificates expired. I read >>>>> several threads explaining how to roll back time and renew them, but I >>>>> then discovered that the host and HTTP certificates for the server were >>>>> missing. I checked for backups, but we erroneously did not cover those >>>>> files. Because they are missing I was unable to rewnew any certificates. >>>>> >>>>> Is there a way to manually create host and service certificates? When I >>>>> search for this, the "manual" procedure listed in the documentation >>>>> requires `ipa cert-request` which does not work. I did try installing a >>>>> self-signed cert for HTTP with `ipa-server-certinstall`. That changed >>>>> the errors, but the commands still fail. The pki-ca services is running >>>>> OK, as far as I can tell. >>>>> >>>>> I also tried adding a CA instance to one of the other replicas with >>>>> `ipa-ca-install`, but it failed during the configuration phase. >>>> The subsystem certificate renewal should be independent of the web (and >>>> host) certificates. I'd focus on getting the CA back up, then we can see >>>> about getting a new web server certificate. >>>> >>>> Can you share the output of: getcert list >>>> >>>> You'll probably want to obfuscate the output as it contains the PIN to >>>> the private key database of the CA. >>>> >>>> rob >>> Here you go. I've also included `certutil -L` outputs. >>> >>> The *auditSigningCert* I tried resubmitting with the time rolled back. >>> The post-save command was also updated, because it wasn't done a year or >>> two back when it replaced our old CRL-signer. >>> >>> `getcert list`: >>> >>> ``` >>> Number of certificates and requests being tracked: 7. >> [ snip ] >> >> What version of IPA is this? > Sorry. It's 3.0.0-37.el6 on Scientific Linux 6x. 389ds is > 220.127.116.11-32.el6_5 and Dogtag is 9.0.3-32.el6. >> You need to modify a few more of these. Take a look at >> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > Thanks. That was in my notes to do for the resubmits. The CS.cfg > changes were made a long while back, before the guide. I think the > ipa-pki-proxy.conf change was inherited with an upgrade. Those are > awesome, BTW, the rpm automated upgrades! The renew_ra_cert script, too. >> When you roll back time are you restarting the pki-cad service? > I think I did, but I can't recall. I will be sure to do it this > weekend when I try again. >> rob >> > Since you pointed out that the certificates and ipa commands should > not be dependent on each other I discovered that the host ticket > needed renewing. The version was out of sync. Running `kinit -kt > /etc/krb5.keytab host/badca.example....@example.com` fixed the ipa > commands and I now get the expected SSL_ERROR_EXPIRED_CERT_ALERT code > when doing a cert-request. Is there anything else I should look at? > > -- > ----- > *question everything*learn something*answer nothing* > ------------ > Lucas Yamanishi > ------------------ > Systems Administrator, ADNET Systems, Inc. > NASA Space and Earth Science Data Analysis (606.9) > 7515 Mission Drive, Suite A100 > Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB To follow up, the second try went well and everything is again running smoothly.
I followed the `getcert stop-tracking`, `getcert start-tracking` procedure described in the *HOWTO Promote a CA* page for all certificates but the *auditSigningCert* on which I previously ran `getcert resubmit`. I'm not sure if it was related to the resubmit or some other side-effect, but the *auditSigningCert* saved into a new index of the NSS DB leaving two identically named indexes, whereas the others saved into their existing indexes on top of their old certificates. I don't know what effect the separate indexes might have had, if any, but I was worried a process selecting it by name would select the wrong cert. It was easy enough to fix by exporting them both in ASCII format, deleting them both, then importing them as a single file. certutil -L -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -a > /root/auditSigningCert.crt certutil -D -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' certutil -D -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' certutil -A -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -i /root/auditSigningCert.crt -t ',,P' Also, for some reason the RA certificate didn't properly publish. Manually running the post-save script was all it took to fix it. /usr/lib64/ipa/certmonger/renew_ra_cert -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project