Open Stack

Yeah, using the system CAs would be my preference but I do understand that
in some cases, things in a virtual environment should stay in that virtual
environment.  Maybe the requests developers would prefer to see the whole
thing isolated, but it does make things rather difficult when requests is a
part of something much larger and more complex.  See
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-11-12.log.html#t2015-11-12T18:20:05
as well, some good discussion going on.

cc'ing Clark specifically since he was so helpful in getting this thing
sorted.


So the consensus here is to discuss using the system CAs with the requests
devs rather than add a config item to OpenStack?

On 16 November 2015 at 05:14, Monty Taylor <mordred at inaugust.com> wrote:

> On 11/15/2015 10:26 AM, Adam Young wrote:
>
>> On 11/14/2015 03:09 AM, Xav Paice wrote:
>>
>>> Hi,
>>>
>>> I'm sure I'm not the only one that likes to use SSL everywhere
>>> possible, and doesn't like to pay for 'real' ssl certs for dev
>>> environments.  Figuring out how to get requests to allow connection to
>>> the self signed cert would have paid for a real cert many times over.
>>>
>>> When I use an SSL cert with a CA not in the Mozilla bundle, and use
>>> keystonemiddleware to access Keystone endpoints, the ssl verification
>>> rightly fails.  It turns out requests doesn't use the system ca cert
>>> bundle, but has it's own.  It's also got a nice easy config option to
>>> set which ca cert bundle you want to use -
>>>
>>> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
>>>
>>> How do people feel about having that as a config option set somewhere,
>>> so we can specify a ca cert in, say, heat.conf, so that we can
>>> continue with the self signed certs of cheapness without needing to
>>> hack up the cacert.pem that comes with requests, or find a way to pass
>>> in environment variables?
>>>
>>> Am I barking up the wrong tree here?  How would I go about writing a
>>> blueprint for this, and for which project?  I guess it's something
>>> that would need to be added to all the projects in the
>>> keystone_authtoken section?  Or is there a central place where common
>>> configs like this can live?
>>>
>>
>>
>> I would say that the right approach is to add the CA to the system
>> bundle for the calling machine.  Requests not using the System defaults
>> is a Bug.
>>
>
>
> Installing CAs into the system is easy, but it might take a little while
> to find the magic incantation:
>
> On Debian derived systems:
>
> - Copy the cert to /usr/local/share/ca-certificates
> - Execute /usr/sbin/update-ca-certificates
>
> On RedHat derived systems:
>
> - Copy the cert to /etc/pki/ca-trust/source/anchors
> - Execute /usr/bin/update-ca-trust extract
>
>
>
> I suspect that the reason that they do this is the unwillingness of the
>> Requests developers to have to battle NSS: The Dogtag developers have a
>> write up including the steps necessary to get NSS support into Requests.
>> http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API
>>
>>
>> On a Fedora system, the python-requests RPM depends on ca-certificates,
>> which is updated more frequently than that document indicates;
>>
>> rpm --query  --list ca-certificates
>>
>> Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as
>> well as /etc/ssl and /usr/share/pki
>>
>>
>> I suspect that Debian based systems do something comparable, although I
>> don't have on handy to chack.
>>
>>
>> So, short answer: use the system tools to update.  Lets not make an end
>> run around system security.  A config value is another path to Audit.
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151116/ff0f19a5/attachment.html>