Open Stack

On Mon, Jun 23, 2014 at 9:59 PM, Tom Fifield <tom at openstack.org> wrote:

> This should be added to the ops guide


Bug logged:
https://bugs.launchpad.net/openstack-manuals/+bug/1333503


>
>
>
> -------- Original Message --------
> Subject: Re: [Openstack] Renewing keystone signing certs
> Date: Tue, 24 Jun 2014 09:37:44 +1000
> From: Sam Morrison <sorrison at gmail.com>
> To: Adam Young <ayoung at redhat.com>
> CC: openstack at lists.openstack.org
>
> Hi Adam,
>
> Thanks for the advice, I’ve tested it out and it is possible to switch
> over pretty seamlessly.
>
> Here is what I did (spelt out in full for others reading):
>
> 1. Generate a new signing key
> 2. Generate a new certificate request
> 3. Sign this with the existing CA to generate a new signing_cert.
> 4. Append the new signing cert to the old signing cert. Make sure the old
> cert is first in the file.
> 5. Remove all signing certs from all your hosts to force nova etc to
> download the new signing_cert(s)
> 6. Replace the signing key with the new signing key AND at the same time
> flip the signing_cert file so the new signing cert is now first in the file.
>
> After the old cert has expired you can safely remove the old signing cert
> from the file.
>
> It would be great if keystoneclient could have a max_age on the
> signing_cert so it would periodically download a fresh one. I would think
> if it downloaded a new one every 7 days or so would suffice.
>
> Cheers,
> Sam
>
>
> On 24 Jun 2014, at 6:23 am, Adam Young <ayoung at redhat.com> wrote:
>
>  On 06/23/2014 03:28 PM, Adam Young wrote:
>>
>>> On 06/23/2014 02:38 AM, Sam Morrison wrote:
>>>
>>>> OK this is looking really scary, (unless I’m missing something…..)
>>>>
>>>> In havana and icehouse, services will only download the signing cert if
>>>> it doesn’t exist. So if you replace it on the keystone server it will
>>>> continue to use the existing cert.
>>>>
>>>> Ideally you should be able to push out both the current and the new
>>>> signing cert to all hosts. Then replace the signing cert in keystone that
>>>> way old and new tokens will work with no downtime
>>>>
>>>> I’m starting to think with the current way keystone does this it’s
>>>> going to mean a cloud wide outage to replace the signing certs?
>>>>
>>>
>>> It might be possible to work around this.
>>>
>>> I have not tested yet, but it might be possible to deploy a file with
>>> both the old an new certs in it to verify the tokens.
>>>
>>> It would be fairly manual, but the process should be something like this:
>>>
>>> 1.  Generate a new certificate key and certificate on the keystone
>>> machine, but not overwriting the existing /etc/keystone/ssl directory
>>> 2.  Append the new certificate to the old certificate
>>> 3.  Replace the certificates in the remote services (one at a time) with
>>> the "dual certificate" file and   confirm that everything still works.
>>> 4.  Replace the key and signing file in the Keystone server with the new
>>> one
>>>
>>> I'll run a quick test to see if the dual cert thing works
>>>
>>
>> It looks like it works OK.  I did the following:
>>
>> cd /opt/stack/python-keystoneclient/examples/pki/certs
>>
>> cat ssl_cert.pem >> signing_cert.pem
>>
>> (edited the file by hand to put a space between the two certs...for
>> legibility if nothing else)
>>
>> cd ..
>>
>> python ./gen_cmsz.py
>>
>>
>> Now while this does throw an error, it has nothing to do with the cert
>> file (same thing happens withou the cert change)  and it has already
>> verified at least one token file before it errors out.
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> On 23 Jun 2014, at 3:28 pm, Sam Morrison <sorrison at gmail.com> wrote:
>>>>
>>>>  Our signing certificate is due to expire in a couple of weeks.
>>>>>
>>>>> I’m trying to figure out the best way to replace it with a new one.
>>>>>
>>>>> I have the new one signed by the same CA but I’m a little unsure of
>>>>> the workflow to replace it. If I swap out the old and new ones will old
>>>>> tokens no longer be valid?
>>>>>
>>>>> Anyone else done this and have thoughts?
>>>>>
>>>>> Cheers,
>>>>> Sam
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>>>> openstack
>>>> Post to     : openstack at lists.openstack.org
>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>>>> openstack
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>>> openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>>> openstack
>>>
>>
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140623/7596e25f/attachment.html>