Created attachment 1266645 [details]
Description of problem:
If using the SSL trusting custom CA as an option for Sec Protocol the provider addition will fail
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Go to Compute --> Containers --> Providers
2. Select Configuration --> Add Existing Provider
3. Add provider's name/hostname/port/token and select SSL trusting custom CA as the option for Sec Protocol
4. Try to validate and add the provider
When attempting to validate the token there's no alert wether validation worked or failed. After pressing the Add button there will be an error screen telling:
hostname "xxxx.redhat.com" does not match the server certificate [ems_container/create]
There should be an alert to tell if the validation succeeded or failed.
The provider addition should work
Added evm.log and production.log with the details
Created attachment 1266648 [details]
Created attachment 1266655 [details]
Created attachment 1266658 [details]
Can reproduce on master (with slightly different symptom, I don't even get the error screen but I see it sent to the browser, perhaps be dev/prod difference?)
[----] F, [2017-03-27T23:50:58.487188 #2693:2ab1edd61f54] FATAL -- : Error caught: [OpenSSL::SSL::SSLError] hostname "ep-ose32-master.scl.lab.tlv.redhat.com" does not match the server certificate
/home/bpaskinc/myenv/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/kubeclient-2.3.0/lib/kubeclient/common.rb:437:in `block in fetch_entities'
We may need to extend https://github.com/ManageIQ/manageiq-ui-classic/pull/314 to rescue all exceptions.
I'm surprised SSLError is escaping out of kubeclient without becoming KubeException. There is specific test for that:
Actually `handle_exception` only catches RestClient::Exception, so I'm surprised that test works.
Figured it out. Solution probably belongs in kubeclient gem. https://github.com/abonas/kubeclient/issues/240
But rescue-all in get_hostname_from_routes might also be prudent.
According to Pavel, he found the positive flow failing: he added the correct CA Certificates and got the failure he described (although the error seems to say the certificate does not match)
Beni please work with him to identify the full range of the error:
Is the positive flow (correct certificate) working? is he using the correct certificate etc.
Your server's certificate doesn't cover the hostname ep-ose32-master.scl.lab.tlv.redhat.com. It covers the IPs.
You can see it by running:
$ openssl s_client -connect ep-ose32-master.scl.lab.tlv.redhat.com:8443 -showcerts < /dev/null | openssl x509 -text
X509v3 Subject Alternative Name:
DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:openshift, DNS:openshift.default, DNS:openshift.default.svc, DNS:openshift.default.svc.cluster.local, DNS:10.35.160.9, DNS:172.30.0.1, IP Address:10.35.160.9, IP Address:172.30.0.1
Using 10.35.160.9 in add provider dialog, I don't get the error, and was able to add it.
For Hawkular I believe using an IP can not work (router relies on sent hostname to know which pods you want to talk to), and you'll have to install a working cert for the right hostname.
The bug with crashing instead of nice error flash still needs to be fixed of course. Let me know if this unblocks you?
(In reply to Beni Paskin-Cherniavsky from comment #8)
> Using 10.35.160.9 in add provider dialog, I don't get the error, and was
> able to add it.
Then this seems a deployment issue. Should we close this as NOTABUG?
(In reply to Beni Paskin-Cherniavsky from comment #9)
> The bug with crashing instead of nice error flash still needs to be fixed of
> course. Let me know if this unblocks you?
OK we can re-purpose this BZ to handle that (instead of closing) but you need to update the title, and make clear what we're going to fix here.
Or you can close this and open a specific BZ.
Re appropriating this per comment 11
OK, exact bug here is that any SSL error except "certificate verify failed"
crashes the UI on pressing [Validate].
To verify the fix you'd actually need a provider with misconfigured SSL :-)
such as ep-ose32-master whose cert does not cover it's hostname.
New commit detected on ManageIQ/manageiq-ui-classic/master:
Author: Beni Cherniavsky-Paskin <email@example.com>
AuthorDate: Sun Apr 9 13:59:22 2017 +0300
Commit: Beni Cherniavsky-Paskin <firstname.lastname@example.org>
CommitDate: Sun Apr 9 13:59:22 2017 +0300
Catch SSLError too when adding a provider
KubeException already covers the common "certificate verify failed" SSL
errors but not rarer ones like "does not match the server certificate".
This might be resolved in Kubeclient or RestClient one day
(https://github.com/abonas/kubeclient/issues/240) but it's blocked
on backward compatibility concerns so let's catch it here for now.
get_hostname_from_routes is best-effort, should never crash UI.
Any SSL error will probably fail both get_hostname_from_routes and the
main validation code; the error from validation will then be displayed
in a red flash.
app/controllers/mixins/ems_common_angular.rb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Beni, the PR you mentioned in comment 14 is merged, is there anything else to handle here or can we move this to POST?
This is still broken in some cases because I caught the wrong exception :-(
Thanks Pavel for finding.
Repro: select "SSL trusting custom CA" mode, write garbage e.g. "x" into Trusted CA Certificates, press Validate.
[----] F, [2017-04-20T15:37:39.951184 #29642:2ac09a5c10f4] FATAL -- : Error caught: [OpenSSL::X509::CertificateError] header too long
/home/bpaskinc/miq/master/app/models/endpoint.rb:58:in `block in parse_certificate_authority'
PR 1120 superceded by https://github.com/ManageIQ/manageiq-ui-classic/pull/1126, merged, waiting for backport.