Open Stack

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
>