Evgeny-- The only reason I see for storing certificate information in Neutron (and not private key information-- just the certificate) is to aid in presenting UI information to the user. Especially GUI users don't care about a certificate's UUID, they care about which hostnames it's valid for. Yes, this can be loaded on the fly whenever public certificate information is accessed, but the perception was that it would be a significant performance increase to cache it.
Stephen On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk <evge...@radware.com> wrote: > Hi folks, > > > > In a current version of TLS capabilities RST certificate SubjectCommonName > and SubjectAltName information is cached in a database. > > This may be not necessary and here is why: > > > > 1. TLS containers are immutable, meaning once a container was > associated to a listener and was validated, it’s not necessary to validate > the container anymore. > This is relevant for both, default container and containers used for SNI. > > 2. LBaaS front-end API can check if TLS containers ids were changed > for a listener as part of an update operation. Validation of containers > will be done for > new containers only. This is stated in “Performance Impact” section of the > RST, excepting the last statement that proposes persistency for SCN and SAN. > > 3. Any interaction with Barbican API for getting containers data > will be performed via a common module API only. This module’s API is > mentioned in > “SNI certificates list management” section of the RST. > > 4. In case when driver really needs to extract certificate > information prior to the back-end system provisioning, it will do it via > the common module API. > > 5. Back-end provisioning system may cache any certificate data, > except private key, in case of a specific need of the vendor. > > > > IMO, There is no real need to store certificates data in Neutron database > and manage its life cycle. > > Does anyone sees a reason why caching certificates’ data in Neutron > database is critical? > > > > Thank you, > > Evg > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev