Description of problem: When adding public signed certificates directly to OCP the webconsole will show invalid request Client state could not be verified. Version-Release number of selected component (if applicable): v3.9.27 How reproducible: All the time Steps to Reproduce: 1. Install OCP 3.9.27 , With public signed certificates. 2. Access webconsole on url https://master.example.com:8443 (it will show invalid cert as it is signed by ocp signer (the internal). 3. Forwarding you to login where it will now be secure and green as you are now in the console pod. 4. Login, 5. - Invalid request Client state could not be verified 6. https://master.example.com:8443/console/error?error=invalid_request&error_description=Client%20state%20could%20not%20be%20verified&error_uri= 7. remove error?error=invalid_request&error_description=Client%20state%20could%20not%20be%20verified&error_uri= Which will place you in the console. Actual results: - Invalid request Client state could not be verified Expected results: Templates selections Additional info: If you type https://master.example.com:8443/console/ the login will work as expected all green. But if you hit https://master.example.com:8443 it seems like you hit the internal URL first (master-int.example.com:8443), before it forwards you to the console, hence giving you the unsecure cert, and perhaps this obscures the URL when logging in. Before webconsole in 3.9 the certificate would be served by one webserver looking at the url when providing the cert, now it is passthrough which potentially will give you this error.
I dont know if this should be seen as a reopen of bug 1537120
This doesn't look certificate related. If you start the login process from domain that doesn't match the console public URL, you'll see the error. It appears that the master is not redirecting you to the public URL in 3.9. This should be fixed in master by https://github.com/openshift/origin/pull/19194 The workaround is to use the console public URL directly. We could check in the console that the domain matches our public URL before starting login to avoid problems like this and bug 1488394. cc David, Simo
First, per comment 2, figured out the steps that stably reproduce the bug in old version which had not merged above PR (OCP v3.9.30): Given the configmap shows consolePublicURL: https://host-8-246-90...redhat.com:8443/console/, access via IP format https://10.8.246.90:8443/console [1]. It will redirect to https://host-8-246-90...redhat.com:8443/login... , input user/password, the error stably happens. [1] https://10.8.246.90:8443 does not reproduce, though Then, test latest v3.10.0-0.64.0 that has merged above PR. It stably reproduces too: its configmap shows consolePublicURL: https://host-8-241-104...redhat.com:8443/console/. Access via IP format https://10.8.241.104:8443/console reproduces the error
(In reply to Xingxing Xia from comment #4) > Then, test latest v3.10.0-0.64.0 that has merged above PR. It stably > reproduces too: its configmap shows consolePublicURL: > https://host-8-241-104...redhat.com:8443/console/. Access via IP format > https://10.8.241.104:8443/console reproduces the error That's expected. The problem fixed by the PR is that the redirect from the master to the console URL didn't use the console public URL. To reproduce, use URL `https://host-8-241-104...redhat.com:8443`. If that works, the problem should be fixed.
Given consolePublicURL and masterPublicURL set as: consolePublicURL: https://host-8-241-104...redhat.com:8443/console/ masterPublicURL: https://host-8-241-104...redhat.com:8443 Visiting masterPublicURL will redirect to consolePublicURL, input u/p will successfully log user in w/o problem
Hi Venkata, If we use following approach, > 1) Open tab A to the console, let it redirect you to the login page, DO NOT LOG IN 2) Open tab B to the console, let it redirect you to the login page, DO NOT LOG IN 3) Complete the log in from tab A. 4) Complete the log in from tab B, it will fail with "Client state could not be verified" At step4, user is expected to fail with "Client state could not be verified" See https://bugzilla.redhat.com/show_bug.cgi?id=1537120#c2 > What this will not change - once you log in through any of the tabs, the nonce will be destroyed so that it can not be reused, this is an intentional security measure. This means any other tabs still sitting on the log in page, you will not be able to just log in on those tabs, you will need to hit the back button to go back to the console.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1816
I do not think that PR applies to 3.9 at all, it was created for new behavior in 3.10 that is not present in 3.9 AFAIK.
Hi, Simo. The console was split out in 3.9. I'm not sure how 3.10 is different?
Ah I may have mixed numbers in my head then ... Venkata, can you open a separate bug referencing/cloning this one for the backport ?