-
Notifications
You must be signed in to change notification settings - Fork 111
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
Comments
See also the UI PR ManageIQ/manageiq-ui-classic#450 for more screenshots. |
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
The value of that parameter will usually be Alternatively, and less secure, if the IP network is trusted, the certificate can be obtained using the
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. |
Doc BZ for container provider docs: https://bugzilla.redhat.com/show_bug.cgi?id=1432260 |
cc @dayleparker @adahms these changes also affected RHV & Middleware providers — are there similar efforts to update those docs?
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. |
@cben - Yes, we have bugs to track the changes required for RHV and Middleware providers here - Hawkular RHV 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! |
@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 |
Hi @cben and @blomquisg, |
perhaps https://bugzilla.redhat.com/show_bug.cgi?id=1429891 "[RFE] Support SSL with Validation (CA) for OpenShift Provider" |
I had this JIRA: https://issues.jboss.org/browse/HAWKULAR-1199 |
Thanks @cben and @josejulio. |
I think this has long been documented and can be closed. |
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 to1
(meaning,true
) it wasn't actually verifying the peer certificate.Additionally, the default was to set
verify_ssl
to1
.The fix being put in place will start enforcing the
verify_ssl
setting. However, it's impossible to know whether the existing value forverify_ssl
is correct or not.The documentation need is to explain that there are two possible outcomes:
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.
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:
In this situation, the user has two options:
A) Configure a custom CA to trust:
B) Disable the certificate validation.
The text was updated successfully, but these errors were encountered: