Bug 1402564

Summary:	TLS Handshake Error - Bad Certificate message despite functioning cluster
Product:	OpenShift Container Platform	Reporter:	Steven Walter <stwalter>
Component:	Installer	Assignee:	Andrew Butcher <abutcher>
Installer sub component:	openshift-ansible	QA Contact:	Johnny Liu <jialiu>
Status:	CLOSED NOTABUG	Docs Contact:
Severity:	medium
Priority:	medium	CC:	abutcher, aos-bugs, bleanhar, ggillies, jokerman, mmccomas, pweil, tatanaka
Version:	3.11.0	Flags:	abutcher: needinfo-
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-24 18:53:31 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:

Description Steven Walter 2016-12-07 20:35:00 UTC

Description of problem:
In order to configure custom certificates, needed to change the masterURL value (to avoid conflicts with masterPublicURL). Thus, needed to run the "redeploy certs" ansible playbook. Customer did this, and deployed the custom/named certificates.

Cluster appears to be working fine; console and cli working with the new certs, and pods running normally. However, getting constant logspam in the master logs.

Version-Release number of selected component (if applicable):
3.3.0

How reproducible:
Unconfirmed


Actual results:


Nov 29 10:42:01 master01.example.com atomic-openshift-master-api[87147]: I1129 10:42:01.610152   87147 server.go:2161] http: TLS handshake error from 10.47.137.125:35469: remote error: bad certificate

Note: that 10.47.137.125 is the HAProxy loadbalancer, not a master or node.


Expected results:
No message

Additional info:
Used openssl to pull the cert being served by 10.47.137.125 ; it is signed by the OpenShift internal signer, and inspecting the cert shows that under the subject alternate names, the master url is signed but not the loadbalancer ip address

Comment 5 Scott Dodson 2017-01-05 22:06:22 UTC

If I'm reading this correctly the cert re-deploy doesn't account for [lb] group and that's the root cause here.

Comment 6 Steven Walter 2017-01-17 17:23:53 UTC

(In reply to Scott Dodson from comment #5)
> If I'm reading this correctly the cert re-deploy doesn't account for [lb]
> group and that's the root cause here.

So to verify, the certificates should have the loadbalancer hostnames in the Subject Alternative Name field?

Comment 9 Scott Dodson 2017-08-24 18:53:31 UTC

Any client that attempts to connect without a matching CA will generate this error. There's no evidence of actual malfunction in this bug so I'm closing it.