Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1382020

Summary:	oc client now will not ignore SSL certificate hostname mismatch even with insecure
Product:	OpenShift Container Platform	Reporter:	Fabiano Franz <ffranz>
Component:	oc	Assignee:	Fabiano Franz <ffranz>
Status:	CLOSED ERRATA	QA Contact:	Xingxing Xia <xxia>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	aos-bugs, ejacobs, jliggitt, jokerman, mmccomas, xiaocwan
Target Milestone:	---
Target Release:	3.3.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: With a malformed master certificate (e.g. expired, mismatched hostname), the latest version of 'oc login' will not ignore this problem even when --insecure-skip-tls-verify is set. Consequence: Users can't login with 'oc' when the server master certificate is invalid. Fix: Handle TLS failures more precisely and allow --insecure-skip-tls-verify to bypass the following error causes: * certificate hostname mismatch * certificate expired * CA not authorized * too many intermediates * usage incompatible with the certificate purpose Result: Users can bypass the certificate error and login with --insecure-skip-tls-verify.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-27 15:42:59 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:
Embargoed:

Description Fabiano Franz 2016-10-05 14:24:32 UTC

With a master certificate that does not contain the "correct" hostname, the latest version of oc will not ignore this problem even when --insecure is set.

Version

origin-clients from centos 1.3.0-3.el7
[root@8a369a8 /]# oc version
oc v1.3.0
kubernetes v1.3.0+52492b4
features: Basic-Auth GSSAPI Kerberos SPNEGO

Steps To Reproduce

create a bad master certificate for the api
try to login
Current Result

(hostnames truncated)

[root@8a369a8 /]# oc login https://master1-b754:8443 --insecure-skip-tls-verify=true -u andrew -p something --loglevel=8
I0927 18:56:02.730036 90 round_trippers.go:296] HEAD https://master1-b754:8443/
I0927 18:56:02.730083 90 round_trippers.go:303] Request Headers:
I0927 18:56:03.090114 90 round_trippers.go:321] Response Status: in 360 milliseconds
I0927 18:56:03.090145 90 round_trippers.go:324] Response Headers:
F0927 18:56:03.090202 90 helpers.go:110] error: x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, master1-15bf, master1.example.com, openshift, openshift.default, openshift.default.svc, openshift.default.svc.cluster.local, 172.30.0.1, 192.168.0.101, not master1-b754

Expected Result

An error/warning perhaps, but a functional login.

Comment 1 XiaochuanWang 2016-10-08 08:41:59 UTC

Verified on openshift v3.3.1.1
# echo "<master_ip> www.example.com" >> /etc/hosts

$ oc login https://www.example.com:8443 -u xiaocwan -p redhat --insecure-skip-tls-verify=true 
Login successful.

(only for compare:) $ oc login https://www.example.com:8443 -u xiaocwan -p redhat
The server is using a certificate that does not match its hostname: x509: certificate is valid for xxx.com, ip-xxx, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, openshift, openshift.default, openshift.default.svc, openshift.default.svc.cluster.local, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, not www.example.com
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): n

error: The server is using a certificate that does not match its hostname: x509: certificate is valid for xxx.com, ip-xxx.xxx.xxx.xxx.internal, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, openshift, openshift.default, openshift.default.svc, openshift.default.svc.cluster.local, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, not www.example.com

Comment 3 errata-xmlrpc 2016-10-27 15:42:59 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.

https://access.redhat.com/errata/RHBA-2016:2084