Bug 1402564 - TLS Handshake Error - Bad Certificate message despite functioning cluster
Summary: TLS Handshake Error - Bad Certificate message despite functioning cluster
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Andrew Butcher
QA Contact: Johnny Liu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-07 20:35 UTC by Steven Walter
Modified: 2022-11-03 13:36 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-24 18:53:31 UTC
Target Upstream Version:
abutcher: needinfo-


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.