Red Hat Bugzilla – Bug 1382020
oc client now will not ignore SSL certificate hostname mismatch even with insecure
Last modified: 2016-10-27 11:42:59 EDT
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.
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
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