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 <[email protected]> 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 <[email protected]> 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 : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
