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.exceptions.SSLError: HTTPSConnectionPool(host='192.168.33.15', port=8200): Max retries exceeded with url: /v1/sys/wrapping/unwrap (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)'),))
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://192.168.33.15:8200/v1
* 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/certs/ca-certificates.crt
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-AES256-GCM-SHA384
* 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_STREAMS updated)!
< 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
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:/