Hi Joe,<br><br>Just to be clear, my interpretation of what Adam is proposing is that unless an organizations CA is specified, Keystone will create a self-signed SSL environment for itself. Totally OK with me. <br><br>This is how Puppet works in a client/server setup and I quite like it a lot. It places more emphasis on the fact that communication is secure than the (potential) hassle of configuring the environment with your existing SSL infrastructure and ensuring all communication points are compatible with that.<br>
<br>This is just my opinion, though. While my organization does use our own key and CA for certain certs, it's not enough to warrant that they are used for every SSL implementation. I'd love to hear what others think -- especially those in larger SSL environments.<br>
<br>Joe<br><br><br><br><div class="gmail_quote">On Sat, Oct 27, 2012 at 2:41 PM, heckj <span dir="ltr"><<a href="mailto:heckj@mac.com" target="_blank">heckj@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adam posted this thread to the OpenStack-dev mailing list, but since some of the context here is what (simple) tooling requirements should exist for establishing SSL certs within the confines of various CA mechanisms, I thought it would be good to get some input from the broader operator community.<br>
<br>
The last paragraph being the one with relevant questions:<br>
<br>
> We can generate a csr based on the hostname of the machine,<br>
> and that way we know that the certificate is formatted for SSL, but is it really<br>
> better to write a tool to do this (it is goingto be done once very year or there<br>
> about) or just point the users at decent documentation about how to do it<br>
> themselves?<br>
...<br>
<br>
The whole message:<br>
<br>
<br>
> -----Original Message-----<br>
> From: Adam Young [mailto:<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>]<br>
> Sent: Friday, October 26, 2012 6:17 PM<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] SSL and devstack<br>
><br>
> Although SSL in Python is slow, we really should enable it in devstack from<br>
> here on out. My understanding is that people with live deployments front<br>
> Keystone with some other SSL terminator. We should thus plan on running<br>
> the python-keystoneclient code through SSL by default to make sure all SSL<br>
> issues are shaken out.<br>
><br>
> If you run keystone-manage --pki_setup it generates a CA certificate for<br>
> you. This is done by default in devstack, in order to get pki tokens to work.<br>
> However, there are no SSL certifcates provided. The config documentation<br>
> states: "a set of sample certficates is provided in the examples/ssl directory<br>
> with the Keystone distribution for testing." However, it uses a different CA<br>
> than the one in the test/signing, so there is no one set of certificates we can<br>
> provide.<br>
><br>
> I think I would like to add an additional option to the keystone-manage<br>
> CLI: --ssl_setup. What I would like to do is gather what the requirements for<br>
> this should be. To start:<br>
><br>
> 1. If no CA is in the path indicated by the config file, generate a self signed<br>
> one. The assumption is that this code will be common between pki and ssl<br>
> setup.<br>
> 2. Use the CA from the above path to sign the ssl certificate.<br>
><br>
> I am assuming that most organizations large enough to have Open Stack have<br>
> their own Public Key Infrastructure. Thus, the self signed CA and SSL cert<br>
> should not be the norm. WHat I am wondering is if there is anything we<br>
> should be doing. For those cases. There is no standard for remotely<br>
> submitting a Certificate Signing Request (CSR) and getting back a signed<br>
> certificate. We can generate a csr based on the hostname of the machine,<br>
> and that way we know that the certificate is formatted for SSL, but is it really<br>
> better to write a tool to do this (it is goingto be done once very year or there<br>
> about) or just point the users at decent documentation about how to do it<br>
> themselves?<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Joe Topjian<div>Systems Administrator</div><div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div><div><br></div>
<div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
<br>