<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 08/07/2014 05:27 PM, Lucas Yamanishi wrote: </div> <blockquote cite="mid:53E3EF3D.1030802@sesda3.com" type="cite"> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <div class="moz-cite-prefix">On 08/07/2014 04:48 PM, Rob Crittenden wrote: </div> <blockquote cite="mid:53E3E604.7080203@redhat.com" type="cite"> <pre wrap="">Lucas Yamanishi wrote: </pre> <blockquote type="cite"> <pre wrap="">On 08/07/2014 01:25 PM, Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">Lucas Yamanishi wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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 </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">[ snip ] What version of IPA is this?</pre> </blockquote> Sorry. It's 3.0.0-37.el6 on Scientific Linux 6x. 389ds is 1.2.11.15-32.el6_5 and Dogtag is 9.0.3-32.el6. <blockquote cite="mid:53E3E604.7080203@redhat.com" type="cite"> <pre wrap="">You need to modify a few more of these. Take a look at <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master">http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master</a></pre> </blockquote> 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. <blockquote cite="mid:53E3E604.7080203@redhat.com" type="cite"> <pre wrap="">When you roll back time are you restarting the pki-cad service?</pre> </blockquote> I think I did, but I can't recall. I will be sure to do it this weekend when I try again. <blockquote cite="mid:53E3E604.7080203@redhat.com" type="cite"> <pre wrap="">rob </pre> </blockquote> 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 <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:host/badca.example.com@EXAMPLE.COM">host/badca.example.com@EXAMPLE.COM</a>` 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? <pre class="moz-signature" cols="72">-- ----- *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</pre> </blockquote> 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 <pre class="moz-signature markdown-here-signature" cols="72">-- ----- *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</pre> </body> </html>