[openstack-dev] Should TLS settings for listener be set through separate API/model?
sbalukoff at bluebox.net
Mon Jun 23 19:15:59 UTC 2014
The separate entity makes sense for certificates participating in an SNI
configuration, but probably not so much for the 'default' certificate used
when TLS is being terminated.
Vijay: You're also right that other TLS-related attributes will probably
get added to the Listener object. This probably makes sense if they apply
to the Listener object as a whole. (This includes things like TLS version
and cipher selection.)
I don't see much of a point in creating a separate object to contain these
fields, since it would have a 1:1 relationship with the Listener. It's true
that for non-TLS-terminated Listeners, these fields wouldn't be used, but
isn't that already the case in many other objects (not just in the Neutron
LBaaS sub project)?
On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan <brandon.logan at rackspace.com>
> I think the separate entity is still going to happen. I don't think it
> has remvoed. Or that is may just be my assumption.
> On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:
> > Hi:
> > In the “LBaaS TLS termination capability specification” proposal
> > https://review.openstack.org/#/c/98640/
> > TLS settings like default certificate container id and SNI cert list are
> part of the listener properties.
> > I think it is better to have this as a separate entity so that the
> listener properties are clean and is not “corrupted” with TLS settings.
> > I liked the original SSL proposal better where TLS settings was a
> separate entity.
> > It is just 2 properties now but in future the TLS settings would grow
> and if we are going to introduce a TLS profile/params/settings entity
> later, it is better to do it now (albeit with min properties).
> > Thanks,
> > Vijay V.
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
Blue Box Group, LLC
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev