<div dir="ltr"><div>Hi,<br><br></div>Tomasz is right. Let's try not to complicate the things. For 6.0 we'll allow just upload key, csr, certificate (like 3 edit boxes), or these edit boxes will be greyed if customer allows to generate self-signed certificates.<br><br><br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div>
<br><div class="gmail_quote">On Wed, Sep 10, 2014 at 1:40 PM, Tomasz Napierala <span dir="ltr"><<a href="mailto:tnapierala@mirantis.com" target="_blank">tnapierala@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 10 Sep 2014, at 12:54, Simon Pasquier <<a href="mailto:spasquier@mirantis.com">spasquier@mirantis.com</a>> wrote:<br>
<br>
> Hello,<br>
<span class="">><br>
> Lets back up a bit and list the different options for Fuel users:<br>
> 0/ The user is happy with plain HTTP.<br>
> => Already supported :)<br>
> 1/ The user wants HTTPS but doesn't want the burden associated with certificate management.<br>
> => Fuel creates and manages the SSL certificates, be them self-signed or signed by some internal CA.<br>
> => Using an internal CA instead of multiple self-signed certificates is cleaner as you explained.<br>
> 2/ The user wants HTTPS and wants to use certificates which are generated by an external source (either some internal corporate PKI or some public certificate authority)<br>
> => Fuel supports certificate + key uploads<br>
> => It should be possible to tell Fuel which entity (Fuel, OSt environment) uses which certificate<br>
> 3/ The user wants HTTPS and agrees to let Fuel generating certificates on behalf of some corporate PKI.<br>
> => Fuel supports CA + key uploads<br>
><br>
> I think that option 1 is the way to go for a first approach. Option 2 is definitely something that end-users would need at some point. I'm less convinced by option 3: if I were a PKI admin, I'll be reluctant to let Fuel generate certificates on its own. Also my gut feeling tells me that implementing 1 & 2 is already quite a lot of work.<br>
><br>
> I've also added some questions/comments inline.<br>
<br>
</span>Regarding<br>
After careful consideration, I think that for 6.0 we will only be able to implement [2] with limited functionality. In terms of certificate management, we could offer uploading customer generated cert (and maybe provide shot doc on how to spawn CA + sign certs) or if user does not want to do it, generate simple self signed cert and install it on Fuel http server and let user download it.<br>
<br>
After 6.0 we can concentrate on proper implementation of CA management, and then allow Fuel master node part to use it.<br>
<span class="im HOEnZb"><br>
[1] <a href="https://blueprints.launchpad.net/fuel/+spec/ca-deployment" target="_blank">https://blueprints.launchpad.net/fuel/+spec/ca-deployment</a><br>
[2] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints</a><br>
[3] <a href="https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints" target="_blank">https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints</a><br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Tomasz 'Zen' Napierala<br>
Sr. OpenStack Engineer<br>
<a href="mailto:tnapierala@mirantis.com">tnapierala@mirantis.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<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>
</div></div></blockquote></div><br></div>