Bug 1589072

Summary: - Invalid request Client state could not be verified
Product: OpenShift Container Platform Reporter: Kim Borup <kborup>
Component: Management ConsoleAssignee: Samuel Padgett <spadgett>
Status: CLOSED ERRATA QA Contact: Yadan Pei <yapei>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.9.0CC: aos-bugs, deads, fshaikh, jokerman, jrosenta, ktadimar, mmccomas, spadgett, ssorce, xxia, yapei
Target Milestone: ---   
Target Release: 3.10.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously, in some configurations, hitting the base URL of the master without the `/console` path could cause the first log in to the web console to fail with a "Client state could not be verified" error. This happened because the redirect to the console did not use the public console URL as defined in the webconsole-config config map in the openshift-web-console namespace. The problem has been fixed and the master will now correctly redirect to the public console URL.
Story Points: ---
Clone Of:
: 1623315 (view as bug list) Environment:
Last Closed: 2018-07-30 19:17:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1623315    

Description Kim Borup 2018-06-08 10:29:30 UTC
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):

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.

Comment 1 Kim Borup 2018-06-08 10:33:08 UTC
I dont know if this should be seen as a reopen of bug 1537120

Comment 2 Samuel Padgett 2018-06-08 12:03:21 UTC
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


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

Comment 4 Xingxing Xia 2018-06-11 06:16:25 UTC
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 [1]. It will redirect to https://host-8-246-90...redhat.com:8443/login... , input user/password, the error stably happens.
[1] 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 reproduces the error

Comment 6 Samuel Padgett 2018-06-12 12:23:13 UTC
(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
> 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.

Comment 7 Yadan Pei 2018-06-13 01:46:47 UTC
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

Comment 12 Yadan Pei 2018-07-23 06:32:53 UTC
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.

Comment 16 errata-xmlrpc 2018-07-30 19:17:19 UTC
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.


Comment 23 Simo Sorce 2018-08-28 12:00:00 UTC
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.

Comment 24 Samuel Padgett 2018-08-28 12:17:04 UTC
Hi, Simo. The console was split out in 3.9. I'm not sure how 3.10 is different?

Comment 25 Simo Sorce 2018-08-28 20:27:05 UTC
Ah I may have mixed numbers in my head then ...

can you open a separate bug referencing/cloning this one for the backport ?