Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The TLS/SSL verify_peer setting is about to change #244

Closed
blomquisg opened this issue Mar 1, 2017 · 11 comments
Closed

The TLS/SSL verify_peer setting is about to change #244

blomquisg opened this issue Mar 1, 2017 · 11 comments
Assignees

Comments

@blomquisg
Copy link
Member

See ManageIQ/manageiq#14019 and ManageIQ/manageiq#14004

The situation is that there was a setting for whether or not to verify the peer certificate when connecting to Container or RHV providers. When verify_ssl was set to 1 (meaning, true) it wasn't actually verifying the peer certificate.

Additionally, the default was to set verify_ssl to 1.

The fix being put in place will start enforcing the verify_ssl setting. However, it's impossible to know whether the existing value for verify_ssl is correct or not.

The documentation need is to explain that there are two possible outcomes:

  1. The user has a valid SSL certificate for their provider and it is signed by a trusted CA (e.g. Verisign). In which case, the user will notice no changes and will need to take no action.

  2. The user has a self-signed SSL certificate for their provider. In which case, either the Schedule Worker or an attempt to collect inventory will render the provider connection invalid:

image

In this situation, the user has two options:

A) Configure a custom CA to trust:

image

B) Disable the certificate validation.

@cben
Copy link
Contributor

cben commented Mar 7, 2017

See also the UI PR ManageIQ/manageiq-ui-classic#450 for more screenshots.

@jhernand
Copy link

jhernand commented Mar 7, 2017

For the oVirt case the user will need to disable TLS certificate verification, or else provide the trusted CA certificates. Both things can be done via the GUI. The key point to make this secure is to make sure that the CA certificates are really trusted. The best way to achieve that is to request the trusted CA certificates from a trusted oVirt administrator, and using a trusted communications channel. The oVirt administrator can find out the CA certificates in use by the oVirt system logging to the oVirt engine machine and checking the SSLCACertificateParameter parameter in the /etc/httpd/conf.d/ssl.conf file:

# grep '^SSLCACertificateFile' /etc/httpd/conf.d/ssl.conf
SSLCACertificateFile /etc/pki/ovirt-engine/apache-ca.pem

The value of that parameter will usually be /etc/pki/ovirt-engine/apache-ca.pem, but it may have been manually changed by the oVirt administrator. The content of that file can be directly pasted in the Trusted CA Certificates text box in the ManageIQ GUI. But it is convenient to remove everything except the text between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marks, to make it shorter.

Alternatively, and less secure, if the IP network is trusted, the certificate can be obtained using the openssl s_client command:

openssl s_client -connect ovirt.example.com:443 -showcerts < /dev/null

That will show the certificate chain presented by the oVirt engine. The last certificate in that chain will be the CA certificate. Note that again that this is less secure than requesting the CA certificate to a trusted oVirt administrator.

@cben
Copy link
Contributor

cben commented Apr 9, 2017

Doc BZ for container provider docs: https://bugzilla.redhat.com/show_bug.cgi?id=1432260

@cben
Copy link
Contributor

cben commented Apr 9, 2017

cc @dayleparker @adahms these changes also affected RHV & Middleware providers — are there similar efforts to update those docs?

  • Containers & RHV started enforcing previously insecure SSL, which may break existing providers until edited.
  • Middleware didn't support HTTPS, so nothing broke, just new options.

ManageIQ/manageiq-ui-classic#759 also moved "Security Protocol" field above hostname, port for several providers whose SSL support didn't change. That PR may be helpful as overview — has screenshots of I believe final look of all affected providers.

@adahms
Copy link
Contributor

adahms commented Apr 9, 2017

@cben - Yes, we have bugs to track the changes required for RHV and Middleware providers here -

Hawkular
https://bugzilla.redhat.com/show_bug.cgi?id=1437286

RHV
https://bugzilla.redhat.com/show_bug.cgi?id=1431869

Thank you for letting us know about the updates - I understand we may need to raise a few more bugs to ensure all changes are updated, and will review #759 for changes as well.

Feel free to let us know at any stage if there are any specific details you feel we should add!

@dayleparker
Copy link
Contributor

@cben, thanks for all the details, it's very helpful.

BTW, we have a new bug now for the OpenShift/RHV SSL updates so as to not hold up the other updated parts of the procedures -- I've added you to the CC list: https://bugzilla.redhat.com/show_bug.cgi?id=1440602

@dayleparker
Copy link
Contributor

Hi @cben and @blomquisg,
We need to link to a downstream bug to publish a Known Issue in the Release Notes (Our RNs bug: https://bugzilla.redhat.com/show_bug.cgi?id=1444325).
Can you please link me to the related engineering bug? I've searched and unfortunately haven't had any luck finding this particular one.
Thank you for your help,
Dayle

@cben
Copy link
Contributor

cben commented Apr 24, 2017

perhaps https://bugzilla.redhat.com/show_bug.cgi?id=1429891 "[RFE] Support SSL with Validation (CA) for OpenShift Provider"
@jhernand @josejulio did you have any BZ for oVirt / Middleware SSL?

@josejulio
Copy link
Member

I had this JIRA: https://issues.jboss.org/browse/HAWKULAR-1199

@dayleparker dayleparker self-assigned this Apr 25, 2017
@dayleparker
Copy link
Contributor

Thanks @cben and @josejulio.
I've tied this known issue in the RNs to BZ#1429891, and have updated the Gitlab repo now.
@adahms, do we need to create doc text, or attach any flags/keywords to the bug to make it an official 'known issue'?

@cben
Copy link
Contributor

cben commented Oct 7, 2018

I think this has long been documented and can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants