Bug 1880865

I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.

This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Additionally, you can add LifecycleFrozen into Keywords if you think this bug should never be marked as stale. Please consult with bug assignee before you do that.

Hi Guys, 

I saw it was parked for 4.7 so I stopped pushing for the fix. The alternative I'm using is to compile my own version of oc to benefit from the fix... 

Cheers.

The LifecycleStale keyword was removed because the bug got commented on recently.
The bug assignee was notified.

I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.

Hello
& happy new year, all the best for 2021 ! 

I see that you're re-opening this, are u willing/planning to get it integrated in 4.7 or am I getting it wrong ?
I had closed the related issue & PR as I had understood from previous comment in the PR.

Thx.

Hello, Happy New year to you too. I am happy to have it fixed in 4.7 and backported to 4.6 as well. However i would like to know if there is any workaround available as of now.

@Novonil,

Don't know if you looked at the analysis of the problem and in particular the inputs provided in the PR: https://github.com/openshift/oc/pull/514 on Sept 9, 2020. The reason of the problem is that even if the user selects the option "--insecure-skip-tls-verify=true" oc makes a first https request to the cluster and tries to validate the certificate (this validation should not happen, as per the request of the user adding the option insecure-skip-tls-verify=true and this is actually the reason for this bug report) which can be fixed with exactly one line of code.

The root cause of the bug is that on mac, certificates verification implemented in the go libraries can be very long and actually as written in the PR updates from Sep 9 (https://github.com/openshift/oc/pull/514#issuecomment-689348366): "...the duration of the checking is mostly coming from certificates with trust policies..."

- So one workaround can be to delete some (unused) certificates with trust policies in the keychain of the end user's mac so that the checking does not take so long, so the timeout does not occur and the connection can be made. 

Two other workarounds are also mentioned in the initial issue that lead to the PR mentioned above and to this bug report, see here: https://github.com/openshift/oc/issues/496
- do a 'sudo oc ...' from the mac, in this case the certificates verification only applies to a subset of the certificates in the keychain (the ones owned by root) and the timeout does not occur(post from July 22nd https://github.com/openshift/oc/issues/496#issuecomment-662164068)
- or add a cacert.pem file as parameter when invoking oc  (even a wrong one) to pass the "hurdle" of the first HEAD https request that fails  and then continue by selecting 'Use insecure connections? (y/n): y' (See here https://github.com/openshift/oc/issues/496#issuecomment-662177056)

Hope this helps.

Lowering the priority to reflect the customer case.

Thanks Frank. We tried the following but still it did not work. We will try the others and update here. 

oc login -u kubeadmin -p ##### --server=https://api.ocp1.example.com:6443 --certificate-authority=./ca.pem --loglevel=9
I0112 14:09:19.747241   11299 loader.go:375] Config loaded from file:  /Users/a600000/.kube/config
I0112 14:09:19.747911   11299 round_trippers.go:423] curl -k -v -XHEAD  'https://api.ocp1.example.com:6443/'
I0112 14:09:29.912408   11299 round_trippers.go:443] HEAD https://api.ocp1.example.com:6443/  in 10164 milliseconds
I0112 14:09:29.912478   11299 round_trippers.go:449] Response Headers:
F0112 14:09:29.912563   11299 helpers.go:115] error: net/http: TLS handshake timeout'

OK...

do you have the problem at a customer site, or are you trying to reproduce the problem on your test system ?
Have you tried:

GODEBUG=x509roots=1 oc login -u kubeadmin -p <myPassword>  api.<myCluster>.<myDomain>:6443

to make sure this is the same problem ?

(In reply to Franck Boudinet from comment #15)
> OK...
> 
> do you have the problem at a customer site, or are you trying to reproduce
> the problem on your test system ?
> Have you tried:
> 
> GODEBUG=x509roots=1 oc login -u kubeadmin -p <myPassword> 
> api.<myCluster>.<myDomain>:6443
> 
> to make sure this is the same problem ?

Frank the problem is with customer site. I do not have a mac to test this.

Reading through https://github.com/golang/go/issues/18203#issuecomment-273005127 I found 
a suggestion to try CGO, we have another issue with mac + vpn (https://bugzilla.redhat.com/show_bug.cgi?id=1838512)
for which we have an open fix https://github.com/openshift/oc/pull/644.
Unfortunately, we can't merge that yet, see the PR comments. 

Can either of you verify if compiling oc with CGO_ENABLED=1 helps with this issue?

A similar issue popped up in https://bugzilla.redhat.com/show_bug.cgi?id=1917756

*** Bug 1917756 has been marked as a duplicate of this bug. ***

(In reply to Maciej Szulik from comment #18)
> Reading through
> https://github.com/golang/go/issues/18203#issuecomment-273005127 I found 
> a suggestion to try CGO, we have another issue with mac + vpn
> (https://bugzilla.redhat.com/show_bug.cgi?id=1838512)
> for which we have an open fix https://github.com/openshift/oc/pull/644.
> Unfortunately, we can't merge that yet, see the PR comments. 
> 
> Can either of you verify if compiling oc with CGO_ENABLED=1 helps with this
> issue?


Hello,

I don't see any difference. It still fails with the same error.

CGO_ENABLED=1
oc login --token=##### --server=https://api.os4.xxx.yyy.com:6443 --loglevel=10
I0120 09:32:09.274984   84808 loader.go:375] Config loaded from file:  /Users/a6002246/.kube/config
I0120 09:32:09.275441   84808 round_trippers.go:423] curl -k -v -XHEAD  'https://api.os4.xxx.yyy.com:6443/'
I0120 09:32:20.029254   84808 round_trippers.go:443] HEAD https://api.os4.xxx.yyy.com:6443/  in 10753 milliseconds
I0120 09:32:20.029311   84808 round_trippers.go:449] Response Headers:
F0120 09:32:20.029379   84808 helpers.go:115] error: net/http: TLS handshake timeout
goroutine 1 [running]:
k8s.io/klog/v2.stacks(0xc00000e001, 0xc000639d40, 0x55, 0xb7)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:996 +0xb9
k8s.io/klog/v2.(*loggingT).output(0x53defc0, 0xc000000003, 0x0, 0x0, 0xc0015b44d0, 0x5183380, 0xa, 0x73, 0x100b300)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:945 +0x191
k8s.io/klog/v2.(*loggingT).printDepth(0x53defc0, 0x3, 0x0, 0x0, 0x2, 0xc00123f5e0, 0x1, 0x1)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:718 +0x165
k8s.io/klog/v2.FatalDepth(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:1449
k8s.io/kubectl/pkg/cmd/util.fatal(0xc0005b80f0, 0x26, 0x1)
        /go/src/github.com/openshift/oc/vendor/k8s.io/kubectl/pkg/cmd/util/helpers.go:93 +0x1f0
k8s.io/kubectl/pkg/cmd/util.checkErr(0x3e29860, 0x54137c0, 0x3b84f40)
        /go/src/github.com/openshift/oc/vendor/k8s.io/kubectl/pkg/cmd/util/helpers.go:188 +0x945
k8s.io/kubectl/pkg/cmd/util.CheckErr(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/kubectl/pkg/cmd/util/helpers.go:115
github.com/openshift/oc/pkg/cli/login.NewCmdLogin.func1(0xc00110edc0, 0xc0015819b0, 0x0, 0x3)
        /go/src/github.com/openshift/oc/pkg/cli/login/login.go:76 +0x5af
github.com/spf13/cobra.(*Command).execute(0xc00110edc0, 0xc001581980, 0x3, 0x3, 0xc00110edc0, 0xc001581980)
        /go/src/github.com/openshift/oc/vendor/github.com/spf13/cobra/command.go:846 +0x2c2
github.com/spf13/cobra.(*Command).ExecuteC(0xc00110eb00, 0x2, 0xc00110eb00, 0x2)
        /go/src/github.com/openshift/oc/vendor/github.com/spf13/cobra/command.go:950 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
        /go/src/github.com/openshift/oc/vendor/github.com/spf13/cobra/command.go:887
main.main()
        /go/src/github.com/openshift/oc/cmd/oc/oc.go:110 +0x885

goroutine 6 [chan receive]:
k8s.io/klog/v2.(*loggingT).flushDaemon(0x53defc0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:1131 +0x8b
created by k8s.io/klog/v2.init.0
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:416 +0xd8

goroutine 49 [select]:
k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0x3b84e68, 0x3e24d60, 0xc0005a2000, 0x1, 0xc000060420)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:167 +0x149
k8s.io/apimachinery/pkg/util/wait.JitterUntil(0x3b84e68, 0x12a05f200, 0x0, 0xc000d05101, 0xc000060420)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:133 +0x98
k8s.io/apimachinery/pkg/util/wait.Until(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:90
k8s.io/apimachinery/pkg/util/wait.Forever(0x3b84e68, 0x12a05f200)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:81 +0x4f
created by k8s.io/component-base/logs.InitLogs
        /go/src/github.com/openshift/oc/vendor/k8s.io/component-base/logs/logs.go:58 +0x8a

goroutine 50 [select]:
io.(*pipe).Read(0xc001391920, 0xc0005ae000, 0x1000, 0x1000, 0x349ec20, 0x1, 0xc0005ae000)
        /opt/rh/go-toolset-1.15/root/usr/lib/go-toolset-1.15-golang/src/io/pipe.go:57 +0xe7
io.(*PipeReader).Read(0xc0002fa250, 0xc0005ae000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /opt/rh/go-toolset-1.15/root/usr/lib/go-toolset-1.15-golang/src/io/pipe.go:134 +0x4c
bufio.(*Scanner).Scan(0xc00147e400, 0x0)
        /opt/rh/go-toolset-1.15/root/usr/lib/go-toolset-1.15-golang/src/bufio/scan.go:214 +0xa9
github.com/openshift/oc/pkg/cli/admin/mustgather.newPrefixWriter.func1(0xc00147e400, 0x3e26720, 0xc00000e018, 0x39a8830, 0x17)
        /go/src/github.com/openshift/oc/pkg/cli/admin/mustgather/mustgather.go:424 +0x13e
created by github.com/openshift/oc/pkg/cli/admin/mustgather.newPrefixWriter
        /go/src/github.com/openshift/oc/pkg/cli/admin/mustgather/mustgather.go:423 +0x1d0

Hi Novonil,

did you try with export GODEBUG=x509roots=1 to really make sure that the problem you're facing is similar to the one I described in my issue ? You should see a list of certificate being one by one checkded and at some point the timeout occuring as they are too many.

Also may I ask which version of oc you're using ? I had put a lot of traces at the time when I investigated, I can have a look if I still have the VM where I did the cross compile to generate the oc mac version with these traces & provided it to you if that helps.

Franck

hi Frank,

Yes tried this already and it is failing too. 

GODEBUG=x509roots=1 oc login --token=### --server=https://api.os4.xxx.yyy.com:6443 --loglevel=9
I0115 09:45:13.504639   84481 loader.go:375] Config loaded from file:  /Users/000000/.kube/config
I0115 09:45:13.506198   84481 round_trippers.go:423] curl -k -v -XHEAD  'https://api.os4.xxx.yyy.com:6443/'
I0115 09:45:24.032962   84481 round_trippers.go:443] HEAD https://api.os4.test.xxx.yyy.com:6443/  in 10526 milliseconds
I0115 09:45:24.032993   84481 round_trippers.go:449] Response Headers:
F0115 09:45:24.033054   84481 helpers.go:115] error: net/http: TLS handshake timeout

We are using oc 4.6.9

OK Novonil,

based on what I read above, my conclusion is that :
  - either you did the test with the export of GODEBUG=x509roots=1 on linux, & I confirm no additional traces are displayed on linux with this option & I think there is no point to do that because the problem I reported was on mac only
  - or either the problem you are having is different from the one I reported

I just double checked with the oc client 4.6.9 on both linux & mac and:
  - on linux the option GODEBUG=x509roots=1 does not display any additional traces as mentionned above
  - but on mac it does, see below an example of the trace your customer should get:
````
GODEBUG=x509roots=1 oc login -u <username> -p <password> https://<myclusterapiurl>:6443 --loglevel=9
I0122 18:23:13.269377   98842 loader.go:375] Config loaded from file:  /Users/fb/.kube/config
I0122 18:23:13.269766   98842 round_trippers.go:423] curl -k -v -XHEAD  'https://<myclusterapiurl>:6443/'
crypto/x509: trust settings for CN=localhost,OU=defaultServer,O=ibm,C=us: 4
crypto/x509: trust settings for CN=localhost:2998,OU=garage,O=hal,L=nice,ST=paca,C=fr,1.2.840.113549.1.9.1=#0c0f66636b626f407961686f6f2e636f6d: 1
crypto/x509: trust settings for CN=sma-unleash.ratl.swg.usma.ibm.com,O=IBM: 4
...
...
````

btw I can also see that compared to the time where I raised the issue using 4.5.x, the oc client behavior has changed from that prospective, most probably some updates in the go librairies being used compared to oc 4.6.9 because here is the trace using oc client 4.5.2 & trying to connect to the same OCP server from exactly the same mac & user:
````
oc.4.5.2 login -u <username> -p <password> https://<myclusterapiurl>:6443 --loglevel=9
I0122 18:32:31.529731   99156 loader.go:375] Config loaded from file:  /Users/fb/.kube/config
I0122 18:32:31.531035   99156 round_trippers.go:423] curl -k -v -XHEAD  'https://<myclusterapiurl>:6443/'
crypto/x509: 189 certs have a trust policy
crypto/x509: verify-cert approved CN=IBM JSS Built-in Certificate Authority
crypto/x509: verify-cert approved CN=IBM Internal Root CA,O=International Business Machines Corporation,C=US
crypto/x509: verify-cert approved CN=ucopia.zonezei,OU=DGSI,O=DA,L=St Cloud,ST=St Cloud,C=FR
crypto/x509: verify-cert approved CN=icp-router,O=IBM Cloud Private,L=Xi'an,ST=Shaanxi,C=CN
crypto/x509: verify-cert approved CN=http://openvpn.net/localca.html #1567088347
crypto/x509: verify-cert rejected CN=1.1.1.1,OU=DeviceSSL (WebAuth),O=Cisco Systems Inc.,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert approved CN=www.ibm.com,O=IBM Cloud Private,L=Armonk,ST=New York,C=US
crypto/x509: verify-cert approved CN=IBM CA,O=International Business Machines Corporation,C=US
...
...
````

You can see that the output is different.
So please confirm that you're getting the 'crypto/x509:' kind of traces when running the oc login from a mac with the GODEBUG=x509roots=1 exports. If yes then hopefully it will help to confirm that the issue is due to the TLS certificates checking taking too long because of too many certificates and if not then it means the problem you're having is different from the one I raised

Have a good WE.
cheers

I spoke with other folks, we'll try to fix the bug in oc in 4.7

Due to other commitments we weren't able to get that resolved for 4.7, I'm pushing this over to 4.8

See the PR from the initial comment, I spoke with Standa and we've decided to go with that fix.

I have opened a new PR to make this change at github.com/openshift/oc/pull/746

Confirmed with latest oc version : 
Zhous-MacBook-Pro:~ zhouying$  oc version --client -o yaml 
clientVersion:
  buildDate: "2021-03-06T04:04:17Z"
  compiler: gc
  gitCommit: f7835631278b03e4388f65145b56e1fd93bf4e37
  gitTreeState: clean
  gitVersion: 4.8.0-202103060050.p0-f783563
  goVersion: go1.15.5
  major: ""
  minor: ""
  platform: darwin/amd64
releaseClientVersion: 4.8.0-0.nightly-2021-03-06-055252


Zhous-MacBook-Pro:~ zhouying$ time oc login  https://api.yinzhou8aws.qe.devcluster.openshift.com:6443 -u pm305  --insecure-skip-tls-verify
WARNING: Using insecure TLS client config. Setting this option is not supported!

Logged into "https://api.yinzhou8aws.qe.devcluster.openshift.com:6443" as "pm305" using existing credentials.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>


real	0m47.463s
user	0m0.304s
sys	0m0.053s

I still have not had a chance to check with the upstream auth folks about the proper way (if any) that we can allow both of these flags to be set.

See https://bugzilla.redhat.com/show_bug.cgi?id=1935102#c2 for more context on why this was reverted. It appears the limitation is not just oc (as previously thought in this bugzilla) but an internal k8s client restriction that will require more work.

Hi,
I hit same issue in our customer environment. Do we have any suggestion for the workaround or solution yet?
While I couldn't use oc cli with this error, I could use curl (with token) to access APIs - all are in same jumpbox and same command window.

The cluster version is 4.10.12.
And I've tested different versions of oc cli, including 4.9.x and 4.10.x.

Detailed log to add for my comment #38: (I've redacted the real server name for customer security reason)


I0602 14:43:35.592176    5296 round_trippers.go:466] curl -v -XHEAD  'https://api.xxxxxxxx:6443/'
I0602 14:43:35.612739    5296 round_trippers.go:495] HTTP Trace: DNS Lookup for api.xxxxxxxx resolved to [{10.202.108.181 } {10.202.44.19 } {10.202.72.125 }]
I0602 14:43:35.615243    5296 round_trippers.go:510] HTTP Trace: Dial to tcp:10.202.108.181:6443 succeed
I0602 14:43:45.646660    5296 round_trippers.go:570] HTTP Statistics: DNSLookup 14 ms Dial 1 ms TLSHandshake 10013 ms Duration 10054 ms
I0602 14:43:45.657887    5296 round_trippers.go:577] Response Headers:
F0602 14:43:45.668757    5296 helpers.go:118] error: net/http: TLS handshake timeout
goroutine 1 [running]:
k8s.io/klog/v2.stacks(0x1)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:1140 +0x8a
k8s.io/klog/v2.(*loggingT).output(0x51c2420, 0x3, 0x0, 0xc0006b6380, 0x2, {0x418b0c7, 0x10}, 0x51c3300, 0x0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:1088 +0x66f
k8s.io/klog/v2.(*loggingT).printDepth(0xc000a07410, 0x26, 0x0, {0x0, 0x0}, 0xc0001da000, {0xc000429f40, 0x1, 0x1})
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:735 +0x1ae
k8s.io/klog/v2.FatalDepth(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:1628
k8s.io/kubectl/pkg/cmd/util.fatal({0xc000a07410, 0x26}, 0xc0009335c0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/kubectl/pkg/cmd/util/helpers.go:96 +0xc5
k8s.io/kubectl/pkg/cmd/util.checkErr({0x39b25a0, 0x521d288}, 0x36b9008)
        /go/src/github.com/openshift/oc/vendor/k8s.io/kubectl/pkg/cmd/util/helpers.go:191 +0x7d7
k8s.io/kubectl/pkg/cmd/util.CheckErr(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/kubectl/pkg/cmd/util/helpers.go:118
github.com/openshift/oc/pkg/cli/login.NewCmdLogin.func1(0xc0008b7400, {0xc000936870, 0x0, 0x5})
        /go/src/github.com/openshift/oc/pkg/cli/login/login.go:77 +0x39f
github.com/spf13/cobra.(*Command).execute(0xc0008b7400, {0xc000936820, 0x5, 0x5})
        /go/src/github.com/openshift/oc/vendor/github.com/spf13/cobra/command.go:860 +0x5f8
github.com/spf13/cobra.(*Command).ExecuteC(0xc0008b7180)
        /go/src/github.com/openshift/oc/vendor/github.com/spf13/cobra/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
        /go/src/github.com/openshift/oc/vendor/github.com/spf13/cobra/command.go:902
k8s.io/component-base/cli.run(0xc0008b7180)
        /go/src/github.com/openshift/oc/vendor/k8s.io/component-base/cli/run.go:146 +0x325
k8s.io/component-base/cli.RunNoErrOutput(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/component-base/cli/run.go:84
main.main()
        /go/src/github.com/openshift/oc/cmd/oc/oc.go:77 +0x365

goroutine 19 [chan receive]:
k8s.io/klog/v2.(*loggingT).flushDaemon(0x0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:1283 +0x6a
created by k8s.io/klog/v2.init.0
        /go/src/github.com/openshift/oc/vendor/k8s.io/klog/v2/klog.go:420 +0xfb

goroutine 10 [select]:
io.(*pipe).Read(0xc000990960, {0xc00094a000, 0x1000, 0xc00051be01})
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/io/pipe.go:57 +0xb7
io.(*PipeReader).Read(0x4, {0xc00094a000, 0xc95c70, 0x2f141e0})
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/io/pipe.go:134 +0x25
bufio.(*Scanner).Scan(0xc0004bcd00)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/bufio/scan.go:215 +0x865
github.com/openshift/oc/pkg/cli/admin/mustgather.newPrefixWriter.func1()
        /go/src/github.com/openshift/oc/pkg/cli/admin/mustgather/mustgather.go:527 +0x105
created by github.com/openshift/oc/pkg/cli/admin/mustgather.newPrefixWriter
        /go/src/github.com/openshift/oc/pkg/cli/admin/mustgather/mustgather.go:526 +0x21a

goroutine 11 [select]:
k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0x0, {0x39adda0, 0xc00088e390}, 0x1, 0xc00008a3c0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:167 +0x13b
k8s.io/apimachinery/pkg/util/wait.JitterUntil(0xc000517fa0, 0x12a05f200, 0x0, 0x10, 0x0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:133 +0x89
k8s.io/apimachinery/pkg/util/wait.Until(...)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:90
k8s.io/apimachinery/pkg/util/wait.Forever(0x0, 0x0)
        /go/src/github.com/openshift/oc/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:81 +0x28
created by k8s.io/component-base/logs.InitLogs
        /go/src/github.com/openshift/oc/vendor/k8s.io/component-base/logs/logs.go:179 +0x85

goroutine 30 [syscall, locked to thread]:
syscall.Syscall9(0x7ff87e3677f0, 0x8, 0x0, 0x175fc0c1e80, 0xc000a0f470, 0x175fc0c2c60, 0xc000a0f560, 0x80, 0x0, 0xc000a0f4c8, ...)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/runtime/syscall_windows.go:510 +0xdb
syscall.CertGetCertificateChain(0x2db3b00, 0x175fc0c1e80, 0xc000a0f470, 0x2000, 0xc000a0f560, 0x80, 0x0, 0xc000a0f4c8)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/syscall/zsyscall_windows.go:388 +0x10d
crypto/x509.(*Certificate).systemVerify(0x0, 0xc000a0f710)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/x509/root_windows.go:250 +0x553
crypto/x509.(*Certificate).Verify(0xc0007c0b00, {0x36b4f70, {0xc00047d840, 0x2d}, 0xc000a26210, 0x0, {0xc09e5105e5c4ced8, 0x3a6e0391, 0x51c1fe0}, {0x0, ...}, ...})
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/x509/verify.go:758 +0x3bd
crypto/tls.(*Conn).verifyServerCertificate(0xc00096e700, {0xc000951ec0, 0x2, 0x2})
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/tls/handshake_client.go:873 +0x665
crypto/tls.(*clientHandshakeStateTLS13).readServerCertificate(0xc000a0fd98)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/tls/handshake_client_tls13.go:461 +0x2d1
crypto/tls.(*clientHandshakeStateTLS13).handshake(0xc000a0fd98)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/tls/handshake_client_tls13.go:91 +0x1f3
crypto/tls.(*Conn).clientHandshake(0xc00096e700, {0x3a00bb0, 0xc000958500})
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/tls/handshake_client.go:222 +0x585
crypto/tls.(*Conn).handshakeContext(0xc00096e700, {0x3a00c58, 0xc000951860})
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/tls/conn.go:1445 +0x3d1
crypto/tls.(*Conn).HandshakeContext(...)
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/crypto/tls/conn.go:1395
net/http.(*persistConn).addTLS.func2()
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/net/http/transport.go:1534 +0x71
created by net/http.(*persistConn).addTLS
        /opt/rh/go-toolset-1.17/root/usr/lib/go-toolset-1.17-golang/src/net/http/transport.go:1530 +0x345

I changed target release to 4.12 after talking with Zhou Ying

The customer mentioned that this issue is happening when they execute "oc login" command from openshift  RHEL client as well? I think we should test this on RHEL as well.

I'd like to note that: The patch fixing the problem is operator system agnostic.

OpenShift has moved to Jira for its defect tracking! This bug can now be found in the OCPBUGS project in Jira.

https://issues.redhat.com/browse/OCPBUGS-8804