certificate verify failed when curl requests succeed to same address
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Barbican-Vault Charm |
Fix Committed
|
High
|
Frode Nordahl |
Bug Description
During a deploy of Openstack with Octavia, Barbican, Vault. This deploy is using a generated SSL certificate and setting hostnames for public address and ip addresses for internal addresses.
Every service is working as expected after unsealing vault EXCEPT barbican-vault, which is erroring with:
requests.
192.168.33.15 is the vault VIP.
from the same machine, however, i can verify that the certificate is connecting and valid:
$ curl -v https:/
* Trying 192.168.33.15...
* TCP_NODELAY set
* Connected to 192.168.33.15 (192.168.33.15) port 8200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.solutionsqa
* start date: Jan 6 18:23:37 2020 GMT
* expire date: Jan 3 18:23:37 2030 GMT
* subjectAltName: host "192.168.33.15" matched cert's IP address!
* issuer: CN=solutionsqa
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55a717334580)
> GET /v1 HTTP/2
> Host: 192.168.33.15:8200
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT
< HTTP/2 404
< cache-control: no-store
< content-type: application/json
< content-length: 14
< date: Thu, 09 Jan 2020 21:42:23 GMT
<
{"errors":[]}
* Connection #0 to host 192.168.33.15 left intact
Crashdump and bundles + ssl keys to follow
Changed in charm-barbican-vault: | |
status: | New → Confirmed |
importance: | Undecided → Critical |
importance: | Critical → High |
Changed in charm-barbican-vault: | |
assignee: | nobody → Frode Nordahl (fnordahl) |
This is most likely a bug in the charm or one of its layers/interfaces. The charm distributes all its dependencies and does not make use of system python packages.
A side effect of that is that the charm code does not get advantage of the Ubuntu patch for the ``certifi`` package which automatically includes system wide TLS certificates for verification of outgoing connections.
For connections to glance this is handled [0], but I do not see this referenced for the code talking to Vault.
So it is most likely easily fixable by passing on the system certificate bundle to the vault client.
0: https:/ /github. com/openstack/ charm-octavia- diskimage- retrofit/ blob/ea828d58e0 196265974be1e1d 316148bd2885453 /src/lib/ charm/openstack /glance_ retrofitter. py#L21