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

Bug 1827539

Summary: Port 22623 will negotiate down to TLS1.1 on master and bootstrap nodes.
Product: OpenShift Container Platform Reporter: Antonio Murdaca <amurdaca>
Component: Machine Config OperatorAssignee: Antonio Murdaca <amurdaca>
Status: CLOSED ERRATA QA Contact: Michael Nguyen <mnguyen>
Severity: medium Docs Contact:
Priority: high    
Version: 4.3.0CC: amurdaca, cscribne, knewcome, miabbott, mnguyen
Target Milestone: ---   
Target Release: 4.4.z   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1823852
: 1827540 (view as bug list) Environment:
Last Closed: 2020-06-17 22:26:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1823852    
Bug Blocks: 1827540    

Comment 1 Antonio Murdaca 2020-05-07 20:20:41 UTC
Waiting on backport approval.

Comment 4 Micah Abbott 2020-06-01 19:31:25 UTC
Verified using 4.4.0-0.nightly-2020-06-01-021027

Launched a cluster on 4.4.6, confirmed that TLS 1.1 connections to master were accepted:

```
$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.4.6     True        False         50m     Cluster version is 4.4.6

$ oc get nodes
NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-131-129.ec2.internal   Ready    worker   57m   v1.17.1
ip-10-0-136-180.ec2.internal   Ready    master   67m   v1.17.1
ip-10-0-141-45.ec2.internal    Ready    worker   57m   v1.17.1
ip-10-0-142-67.ec2.internal    Ready    master   66m   v1.17.1
ip-10-0-146-233.ec2.internal   Ready    master   67m   v1.17.1
ip-10-0-157-133.ec2.internal   Ready    worker   57m   v1.17.1

$ oc debug node/ip-10-0-136-180.ec2.internal
Starting pod/ip-10-0-136-180ec2internal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.136.180
If you don't see a command prompt, try pressing enter.
sh-4.2# chroot /host

sh-4.4# openssl s_client -CAfile /etc/kubernetes/static-pod-resources/etcd-member/ca.crt -tls1_3 -quiet -connect localhost:22623
Can't use SSL_get_servername
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=21:unable to verify the first certificate
verify return:1
^C
sh-4.4# openssl s_client -CAfile /etc/kubernetes/static-pod-resources/etcd-member/ca.crt -tls1_2 -quiet -connect localhost:22623
Can't use SSL_get_servername
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=21:unable to verify the first certificate
verify return:1
^C
sh-4.4# openssl s_client -CAfile /etc/kubernetes/static-pod-resources/etcd-member/ca.crt -tls1_1 -quiet -connect localhost:22623
Can't use SSL_get_servername
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=21:unable to verify the first certificate
verify return:1
^C
```

Upgraded the cluster to 4.4.0-0.nightly-2020-06-01-021027 and now TLS 1.1 connections are refused:

```
$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.4.0-0.nightly-2020-06-01-021027   True        False         5m40s   Cluster version is 4.4.0-0.nightly-2020-06-01-021027
[miabbott@toolbox (container) ~/Downloads ]$ oc get nodes
NAME                           STATUS   ROLES    AGE    VERSION
ip-10-0-131-129.ec2.internal   Ready    worker   105m   v1.17.1
ip-10-0-136-180.ec2.internal   Ready    master   115m   v1.17.1
ip-10-0-141-45.ec2.internal    Ready    worker   105m   v1.17.1
ip-10-0-142-67.ec2.internal    Ready    master   115m   v1.17.1
ip-10-0-146-233.ec2.internal   Ready    master   115m   v1.17.1
ip-10-0-157-133.ec2.internal   Ready    worker   105m   v1.17.1
[miabbott@toolbox (container) ~/Downloads ]$ oc debug node/ip-10-0-136-180.ec2.internal
Starting pod/ip-10-0-136-180ec2internal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.136.180
If you don't see a command prompt, try pressing enter.
sh-4.2# chroot /host

sh-4.4# openssl s_client -CAfile /etc/kubernetes/static-pod-resources/etcd-member/ca.crt -tls1_3 -quiet -connect localhost:22623
Can't use SSL_get_servername
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=21:unable to verify the first certificate
verify return:1

sh-4.4# openssl s_client -CAfile /etc/kubernetes/static-pod-resources/etcd-member/ca.crt -tls1_2 -quiet -connect localhost:22623
Can't use SSL_get_servername
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = api-int.ci-ln-4ctdtxt-d5d6b.origin-ci-int-aws.dev.rhcloud.com
verify error:num=21:unable to verify the first certificate
verify return:1
^C

sh-4.4# openssl s_client -CAfile /etc/kubernetes/static-pod-resources/etcd-member/ca.crt -tls1_1 -quiet -connect localhost:22623
140088385931072:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70
```

Comment 7 Kirsten Newcomer 2020-06-15 10:44:01 UTC
I believe the fix version for this BZ should be 4.4. The BZ for 4.3 is https://bugzilla.redhat.com/show_bug.cgi?id=1827540

Comment 8 Antonio Murdaca 2020-06-15 10:56:43 UTC
(In reply to Kirsten Newcomer from comment #7)
> I believe the fix version for this BZ should be 4.4. The BZ for 4.3 is
> https://bugzilla.redhat.com/show_bug.cgi?id=1827540

Both the Target release field and the linked PR are indeed 4.4. The only thing at 4.3 is the Version which should be where the bug was first found, am I missing something? The linked BZ is the clone, still a bug in 4.3 but with Target 4.3 for the patch release.

Comment 10 Kirsten Newcomer 2020-06-15 13:32:22 UTC
(In reply to Antonio Murdaca from comment #8)
> (In reply to Kirsten Newcomer from comment #7)
> > I believe the fix version for this BZ should be 4.4. The BZ for 4.3 is
> > https://bugzilla.redhat.com/show_bug.cgi?id=1827540
> 
> Both the Target release field and the linked PR are indeed 4.4. The only
> thing at 4.3 is the Version which should be where the bug was first found,
> am I missing something? The linked BZ is the clone, still a bug in 4.3 but
> with Target 4.3 for the patch release.

Good to know. Thanks! Looks like I'm the one who missed something! :-) For some reason, the Target Release field isn't visible for me. Unless I'm just not seeing it, which is possible.

Comment 11 Kirsten Newcomer 2020-06-15 13:33:41 UTC
(In reply to Kirsten Newcomer from comment #10)
> (In reply to Antonio Murdaca from comment #8)
> > (In reply to Kirsten Newcomer from comment #7)
> > > I believe the fix version for this BZ should be 4.4. The BZ for 4.3 is
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1827540
> > 
> > Both the Target release field and the linked PR are indeed 4.4. The only
> > thing at 4.3 is the Version which should be where the bug was first found,
> > am I missing something? The linked BZ is the clone, still a bug in 4.3 but
> > with Target 4.3 for the patch release.
> 
> Good to know. Thanks! Looks like I'm the one who missed something! :-) For
> some reason, the Target Release field isn't visible for me. Unless I'm just
> not seeing it, which is possible.

Found it! I needed to click Show Advanced Fields. Sorry for the noise!

Comment 12 errata-xmlrpc 2020-06-17 22:26:03 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-2020:2445