Document setup of a user's key and certifcate for the server and CLI

[kholdaway]

@elyezer commented on Fri Feb 02 2018

Opening a new issue

---

Specify type:

• Enhancement

---

Description:

The certificate used to deploy quipucords can't really validate the HTTPS connection if someone wants to do that.

---

Bug Report

Expected behavior:

The certificate should be able to validate the HTTPS connection

Actual behavior:

The HTTPS validation fails

Steps to reproduce:

Build and run the docker image and then configure the qpc client without the --ssl-verify option:

$ qpc server config --host localhost 
$ qpc cred list
Error: Invalid token.
usage: qpc cred list [-h] [--type TYPE]

optional arguments:
  -h, --help   show this help message and exit
  --type TYPE  Filter for listing credentials by type. Valid values: vcenter,
               network.

It works because the default behavior of the client is to ignore SSL errors. Now trying to validate the HTTPS connection it fails:

$ qpc server config --host localhost --ssl-verify deploy/ssl/server.crt 
$ qpc cred list                                                        
A connection error occurred while attempting to communicate with the server over "https". To troubleshoot this problem, check the configuration and the status of the server.
HTTPSConnectionPool(host='localhost', port=443): Max retries exceeded with url: /api/v1/credentials/ (Caused by SSLError(CertificateError("hostname 'localhost' doesn't match 'ANY'",),))

Environment information:

N/A

---

@chambridge commented on Fri Feb 02 2018

I don't really see this as a bug. The intent was to provide minimal SSL (so we have encryption out-of-the-box). Then if the user wanted a valid cert they would have to purchase one or create a self-signed certificate with the valid information including the hostname that would be running the server.

The container exposes the /etc/ssl directory for mounting so a user can swap out the cert and keyfile with their valid keyfile & cert. Then they could utilize the cert with the CLI. The intent was to doc this for as advanced usage for the 1.0. Just hasn't been done yet.

---

@elyezer commented on Fri Feb 02 2018

I see.

I was planning to use the certificate on the automation so we could simulate someone which would be validating the certificate. So it seems I need to create and handle the certificate myself for the testing environment.

If there is a bug already to document that, then we can close this. Even though I think it would be great to have a working certificate out of the box.

---

@chambridge commented on Fri Feb 02 2018

I'm happy to turn this into an enhancement for the advanced documentation around configuring the server and CLI with the customers own SSL cert.

However, I want to be clear that there isn't a way to ship out of the box with a cert that works for any server since the host/ip is part of the cert validation.

I don't expect most customers will ever do these advanced steps since the server they are pointing to is running on-prem within there network. The point was to deliver an out-of-the-box experience that provided SSL encryption between the CLI and server, which is what is currently being achieved.

---

@ghost commented on Tue Apr 17 2018

Can we not use a static key but generate one? if they use a static key then they can more easily be man in the middle attacked if that key is ever shown (because it is shared).

[jlprevatt-zz]

@kholdaway Requesting an update on this issue--the original request is more than a year old. Also, it contains ideas and discussion around a situation that would result in a documentation change, but no actual information about what the documentation change should be.