Open Stack

On 06/23/2014 07:37 PM, Sam Morrison wrote:
> 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.

Even better would be for it to look at the expiration date of the 
certificate and look for a fresh download if we are close to expired.    
Tweakable params would be how often to check, and how big a window to 
consider for a download.

I'd also suspect a lot of people would really benefit by CRL checking.  
If a cert is revoked, Auth token  should  detect.



>
> 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