1. Proposed title of this feature request

Easy recovery from login failures to an OpenShift cluster caused by expired ingress certificates.

2. What is the nature and description of the request?

The interaction pattern between oc login and the cluster is changed in a way where the use of the --insecure-skipl-tls-verify switch is effective in a situation where OCP ingress cert expired. Setting the switch to false correctly ignores that the ingress endpoint used to get a new Oauth token has an expired cert.

3. Why does the customer need this?

Today, --insecure-skipl-tls-verify only works for OCP API endpoints. Because oc login is contacting a standard ingress endpoint it fails with TLS handshake errors because it still tries to validate the TLS connection to the ingress endpoint.

The proposed alternative is having the customer recover access to the cluster by reaching to the master nodes and manually deploy a custom KUBECONFIG. This is the only way to recover / reset the ingress certs, especially if the console is not reachable or not working.

We recently encountered this on the BU Hub Cluster where an expired cert caused the console login to end in an endless loop for all login options. Trying to renew the certificate via oc failed like above. The recovery procedure is excessive. The correct behavior to ignore TLS validation on ALL connections to the cluster (and not just API endpoints) should be implemented.

Background: https://access.redhat.com/solutions/6632521 and https://dentrassi.de/2021/01/18/recovering-from-an-expired-openshift-certificate/

4. List any affected packages or components.

oc login