Hi Rob

And thanks for the new instructions. However, right out of the gate:

$ ipa-csreplica-manage set-renewal-master
Usage: ipa-csreplica-manage [options]

ipa-csreplica-manage: error: must provide a command [force-sync |
disconnect | list | del | connect | re-initialize]

Are there any RHEL6 specific instructions I can follow to the promised land?

On Wed, May 20, 2015 at 8:30 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
> Sina Owolabi wrote:
>> Hi Rob
>> This is the only CA master. The one I cloned it from was
>> decommissioned,  reinstalled and then  made to be a replica of this
>> server.
>> Looks like I'm really stuck.  How do I export the data out so I can
>> reinstall from scratch, if possible? There are a lot of rules and
>> configuration data I'd really like to keep.
> So in this case you have no master managing the renewal.
> Take a look at
> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0
> starting at the step "Reconfigure a CA as the new master"
> Since at least one certificate has expired you'll need to go back in time to
> get this working. Be sure to restart IPA after going back to ensure that the
> CA is up.
> You'll eventually want to do the CRL changes as well.
> rob
>> On Wed, May 20, 2015, 2:32 PM Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>     Sina Owolabi wrote:
>>      > Another key difference I noticed is that the problematic certs have
>>      > CA:IPA in them, while the working certs have CA:
>>      > dogtag-ipa-retrieve-agent-submit.
>>     Ok, the full output is really helpful.
>>     First an explanation of CA subsystem renewal.
>>     CA clones are just that, exact clones of each other, which means they
>>     use the same subsystem certificates for OCSP, audit, etc. This also
>>     means that at renewal time they need to be renewed on only one master
>>     and then somehow shared with the ohter clones.
>>     The initially-installed CA is designated as the renewal master by
>>     default. It configures certmonger to renew the CA subsytem
>> certificates
>>     and put the new public cert into a shared area in IPA that will be
>>     replicated to the other masters.
>>     The non-renewal masters are configured with a special CA,
>>     dogtag-ipa-retrieve-agent-submit, that looks in this shared area for
>> an
>>     updated certificate and when available, it installs it.
>>     So the issue is that it isn't seeing this updated certificate, hence
>>     CA_WORKING.
>>     The CA_UNREACHABLE are due to the fact that the IPA RA agent
>> certificate
>>     that IPA uses to talk to the CA expired on 04/29.
>>     So the steps you need to take are:
>>     1. Check your other CA masters and see if they have been renewed
>>     properly (getcert list will tell you, look for expiration in 2017).
>>     2. If they have, see if the data was pushed to LDAP
>>     $ kinit admin
>>     $ ldapsearch -Y GSSAPI -b
>> cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com
>>     See if there are certificate entries there. Check on multiple masters
>> to
>>     see if there is a replication issue.
>>     If the certs are there you can try restarting certmonger to kickstart
>>     the request.
>>     rob

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to