"openstack network list" fails with "An SSL error occurred."
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Mirantis OpenStack |
Undecided
|
Unassigned | ||
| python-openstackclient |
Fix Released
|
Medium
|
Richard Theis |
Bug Description
Running "openstack network list" fails with "An SSL error occurred" with python-
Other commands, like "openstack server list" work with the same version.
$ openstack --version
openstack 2.1.0
$ openstack server list >/dev/null # Works
$ openstack network list >/dev/null # Fails
An SSL error occurred.
Running "openstack network list" works with python-
$ openstack --version
openstack 2.0.0
$ openstack server list >/dev/null # Works
$ openstack network list >/dev/null # Works
$
Rahul U Nair (rahulunair) wrote : | #1 |
Svend Sorensen (svendsorensen) wrote : | #2 |
Output from "openstack --debug network list" is attached.
Rahul U Nair (rahulunair) wrote : | #3 |
Can you attach the output of openstack --debug server list as well?
Svend Sorensen (svendsorensen) wrote : | #4 |
Output of "openstack server --debug list --name bugreport" is attached.
Dean Troyer (dtroyer) wrote : | #5 |
Are the compute and network endpoints configured the same? ie, do they use the same SSL/TLS termination or configuration?
Terry Howe (thowe-g) wrote : | #6 |
If you hit the network endpoint in a browser does it have a valid cert?
Also, does 'openstack network list --insecure' work?
Terry Howe (thowe-g) wrote : | #7 |
openstack catalog list
should give you a list of endpoints.
Richard Theis (rtheis) wrote : | #8 |
Can you please provide the output of "pip list"?
Svend Sorensen (svendsorensen) wrote : | #9 |
Output of pip list is attached.
Svend Sorensen (svendsorensen) wrote : | #10 |
I get the same error with --insecure:
$ openstack network list --insecure
An SSL error occurred.
Svend Sorensen (svendsorensen) wrote : | #11 |
The endpoints are all using the same wildcard certificate.
Dean Troyer (dtroyer) wrote : | #12 |
The --insecure bit is a clue, it's internal to OSC, probably connected to the use of the SDK with the network commands and not the others. We may not be setting up TLS correctly there.
Changed in python-openstackclient: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Richard Theis (rtheis) wrote : | #13 |
It appears that OSC may need to pass verification information when building the connection using the SDK. I'll try recreating this.
Richard Theis (rtheis) wrote : | #14 |
I deployed a DevStack environment with the tls-proxy service enabled and could not recreate the error.
ubuntu@
openstack 2.2.1
ubuntu@
...
ubuntu@
OS_REGION_
OS_PROJECT_
OS_IDENTITY_
OS_PASSWORD=
OS_AUTH_URL=https:/
OS_USERNAME=admin
OS_TENANT_
OS_VOLUME_
OS_NO_CACHE=1
Richard Theis (rtheis) wrote : | #15 |
I tried deploying a DevStack environment with USE_SSL=True but that failed.
Cedric Brandily (cbrandily) wrote : | #16 |
OSC 2.2.1 authenticates twice when performing a neutron-related command: the 1st one with cacert/verify information which succeeds, the 2nd one without them which fails
Richard Theis (rtheis) wrote : | #17 |
Does anyone know how to recreate this using a DevStack deployment?
Svend Sorensen (svendsorensen) wrote : | #18 |
Is there a way to enable SSL in devstack with an existing certificate?
Richard Theis (rtheis) wrote : | #19 |
The following also worked in my DevStack environment with the tls-proxy service enabled.
$ OS_CACERT=
...
Changed in python-openstackclient: | |
assignee: | nobody → Richard Theis (rtheis) |
Fix proposed to branch: master
Review: https:/
Changed in python-openstackclient: | |
status: | Confirmed → In Progress |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit b5f10f43eb9fd1a
Author: Richard Theis <email address hidden>
Date: Thu Apr 7 16:35:38 2016 -0500
Fix SSL/TLS verification for network commands
The network commands ignored the --insecure and --os-cacert
options and OS_CACERT environment variable which prevented
them from properly completing SSL/TLS verification. This
resulted in the network commands failing with
"An SSL error occurred."
Change-Id: I15167631ef5833
Closes-Bug: #1560157
Changed in python-openstackclient: | |
status: | In Progress → Fix Released |
This issue was fixed in the openstack/
Alexander Bozhenko (alexbozhenko) wrote : | #23 |
Could somebody please backport it to Mitaka as well?
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-openstackclient (stable/mitaka) | #24 |
Fix proposed to branch: stable/mitaka
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Change abandoned on python-openstackclient (stable/mitaka) | #25 |
Change abandoned by Steve Martinelli (<email address hidden>) on branch: stable/mitaka
Review: https:/
Reason: rich, seems like not
Richard Theis (rtheis) wrote : | #26 |
Hi Alexander. OSC normally only backports security fixes to stable branches. Please contact Dean Troyer (dtroyer) if you believe an exception to this policy is needed.
FYI: OSC 2.4.0 should be backwards compatible with Mitaka.
Changed in mos: | |
status: | New → Confirmed |
Dmitry Mescheryakov (dmitrymex) wrote : | #27 |
Alexander, Sergii, that fix was backported in downstream MOS 9.1 as bug https:/
Setting state of the current bug in MOS as invalid, as there is no way to specify state for a single project as duplicate.
Changed in mos: | |
status: | Confirmed → Invalid |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: stable/mitaka
commit 53a79c33f88cea8
Author: Richard Theis <email address hidden>
Date: Thu Apr 7 16:35:38 2016 -0500
Fix SSL/TLS verification for network commands
The network commands ignored the --insecure and --os-cacert
options and OS_CACERT environment variable which prevented
them from properly completing SSL/TLS verification. This
resulted in the network commands failing with
"An SSL error occurred."
Change-Id: I15167631ef5833
Closes-Bug: #1560157
(cherry picked from commit b5f10f43eb9fd1a
tags: | added: in-stable-mitaka |
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/python-openstackclient 2.3.1 | #29 |
This issue was fixed in the openstack/
Kindly attach the logs you get when this command is run ::
openstack --debug network list