Description of problem: ======================= Octavia provides a script for generating certificates, as mentioned here[1], but I'm not sure this is what we expect our customers to do. Moreover, we currently exclude[2] this script from our packaging, so we don't even currently ship it. The end result we aim to achieve here is to have a tripleO doc (which is WIP[3]) that guides the operator on how exactly he/she should deploy Octavia. As currently some steps are executed manually. The certificates part is currently expected to be executed before[3] the deployment even starts, yet it is not clear how/what we expect the operator to do and what is the best practice for secure certificate configuration. To the best of my knowledge, we have two alternatives here: 1. Use the solution mentioned in https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/tls_everywhere.html 2. Use and ship the Octavia certificates creation script: https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh [1] https://docs.openstack.org/developer/octavia/guides/dev-quick-start.html#create-octavia-keys-and-certificates [2] https://github.com/rdo-packages/octavia-distgit/blob/rpm-master/openstack-octavia.spec#L336 [3] https://review.openstack.org/#/c/447496/20/doc/source/advanced_deployment/octavia-post-deploy.sh@263
It's not clear that the spirit of "TLS everywhere" is compatible with "as a service" components like octavia and likely warrants a larger conversation including storage and anyone seeking to integrate other "as a service" components. The original intent of this bug was to find out the proper way to integrate cert generation into the deployment. I'm updating the title of the bug accordingly.
We are now in a middle of discussion about how to generate or import the certificate. For user-provided certificate, we have already a solution by copying the certificate content into an environment file. For auto-generated certificate, we should see if TLS Everywhere can somehow intergate with Octavia and if it's the right thing to do, as this should lead to additional manual steps before deploying the overcloud (such as create manually CA files or install FreeIPA server) + all other TLS/SSL supported services will enable encrypted socket. Up to now we generated self-signed certificates by using OpenSSL CLI.
The fix has already landed the the puddle
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2086