<div dir="ltr">We were adding our CA to the bundle, we are using python-requests. python-requests is getting installed via pip in a venv, and it includes it's own CA bundle. So we were creating a symlink from the system bundle to the venv requests bundle. Then something upgraded python-requests in the venv, which overwrote the symlink, which actually overwrote the system bundle, for maximum lols.<div><br></div><div>At that point we decided to go with the openstack config file route :)</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">- jlk</div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 25, 2015 at 2:03 PM, John Dewey <span dir="ltr"><<a href="mailto:john@dewey.ws" target="_blank">john@dewey.ws</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
I faced this very issue in the past. We solved the problem by adding the CA to the system bundle (as you stated). We also ran into problems where python would still not validate the CA. However, this turned out to be a permissions error with cacerts.txt[1] when httplib2 was installed through pip. Nowadays openstack uses requests which I don’t believe utilizes httplib2.</div><div><br></div><div>[1] <a href="https://code.google.com/p/httplib2/issues/detail?id=292&q=certificate" target="_blank">https://code.google.com/p/httplib2/issues/detail?id=292&q=certificate</a></div><div><div class="h5">
<div></div>
<p style="color:#a0a0a8">On Wednesday, March 25, 2015 at 11:13 AM, Jesse Keating wrote:</p>
</div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div class="h5"><div><div dir="ltr">We're facing a bit of a frustration. In some of our environments, we're using a self-signed certificate for our ssl termination (haproxy). We have our various services pointing at the haproxy for service cross-talk, such as nova to neutron or nova to glance or nova to cinder or neutron to nova or cinder to glance or all the things to keystone. When using a self-signed certificate, these services have trouble validating the cert when they attempt to talk to each other. This problem can be solved in a few ways, such as adding the CA to the system bundle (of your platform has such a thing), adding the CA to the bundle python requests uses (because hilariously it doesn't always use the system bundle), or the more direct way of telling nova, neutron, et al the direct path to the CA file.<div><br></div><div>This last choice is the way we went forward, more explicit, and didn't depend on knowledge if python-requests was using its own bundle or the operating system's bundle. To configure this there are a few places that need to be touched.</div><div><br></div><div>nova.conf:</div><div>[keystone_authtoken]</div><div>cafile = <path></div><div><br></div><div>[neutron]</div><div>ca_certificates_file = <path></div><div><br></div><div>[cinder]</div><div>ca_certificates_file = <path></div><div><br></div><div>(nothing for glance hilariously)</div><div><br></div><div><br></div><div>neutron.conf</div><div><div>[DEFAULT]</div></div><div>nova_ca_certificates_file = <path></div><div><br></div><div>[keystone_authtoken]</div><div>cafile = <path></div><div><br></div><div>glance-api.conf and glance-registry.conf</div><div>[keystone_authtoken]</div><div>cafile = <path></div><div><br></div><div>cinder.conf</div><div>[DEFAULT]</div><div>glance_ca_certificates_file = <path></div><div><br></div><div>[keystone_authtoken]</div><div>cafile = <path></div><div><br></div><div>heat.conf</div><div>[clients]</div><div>ca_file = <path></div><div><br></div><div>[clients_<whatever>]</div><div>ca_file = <path></div><div><br></div><div><br></div><div>As you can see, there are a lot of places where one would have to define the path, and the frustrating part is that the config name and section varies across the services. Does anybody think this is a good thing? Can anybody think of a good way forward to come to some sort of agreement on config names? It does seem like heat is a winner here, it has a default that can be defined for all clients, and then each client could potentially point to a different path, but every config entry is named the same. Can we do that across all the other services?</div><div><br></div><div>I chatted a bit on twitter last night with some nova folks, they suggested starting a thread here on ops list and potentially turning it into a hallway session or real session at the Vancouver design summit (which operators are officially part of).</div><div><div><div><div><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">- jlk</div></div></div></div></div>
</div></div></div></div></div>
</div></div></div><div><div>_______________________________________________</div><div>OpenStack-operators mailing list</div><div><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a></div><div><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></div></div></div></span>
</blockquote>
<div>
<br>
</div>
</blockquote></div><br></div>