[Freeipa-users] Certificate system unavailable [solved]

[Lucas Yamanishi]

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
> 1.2.11.15-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.com at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140814/92b739d0/attachment.htm>