Bug 1717428 - Presence of internal openshift ca certificates in /etc/pki/ca-trust/source/anchors/ in OCP 3.7 by default but not since OCP 3.10 or in 3.11
Summary: Presence of internal openshift ca certificates in /etc/pki/ca-trust/source/an...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.11.0
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: ---
: 3.11.z
Assignee: Joseph Callen
QA Contact: Weihua Meng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-05 13:11 UTC by Vedanti Jaypurkar
Modified: 2019-09-03 15:56 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The OpenShift CA certificate was not copied to the nodes or added to the system's trusted root. Consequence: Using a openshift endpoint that uses SSL communication failed or required insecure option Fix: Add to the node sync pod to copy the CA to trust anchor and run update-ca-trust Result: SSL communication to OpenShift endpoints is now trusted.
Clone Of:
Environment:
Last Closed: 2019-09-03 15:56:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2580 0 None None None 2019-09-03 15:56:21 UTC

Description Vedanti Jaypurkar 2019-06-05 13:11:34 UTC
Description of problem:

Some differences were observed while logging into the cluster using `oc` binary in 3.7 and 3.11  when using self signed certificates.
While login into the cluster using below command  
# oc login -u <user-name> https://<masterurl>:port 

It prompts for accepting the insecure connection in OCP 3.11 but its does not prompt for the same in OCP 3.7 as shown below -

========================
The server uses a certificate signed by an unknown authority.
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 uses a certificate signed by unknown authority. You may need to use the --certificate-authority flag to provide the path to a certificate file for the certificate authority, or --insecure-skip-tls-verify to bypass the certificate check and use insecure connections.

========================

When checked with the code, function "promptForInsecureTLS" is being called in 3.11 while logging in from CLI, the same function is present in 3.7 code as well but still the issue is seen in 3.11.

===========================
func promptForInsecureTLS(reader io.Reader, out io.Writer, reason error) bool {
        var insecureTLSRequestReason string
        if reason != nil {
                switch reason.(type) {
                case x509.UnknownAuthorityError:
                        insecureTLSRequestReason = "The server uses a certificate signed by an unknown authority."
                case x509.HostnameError:
                        insecureTLSRequestReason = fmt.Sprintf("The server is using a certificate that does not match its hostname: %s", reason.Error())
                case x509.CertificateInvalidError:
                        insecureTLSRequestReason = fmt.Sprintf("The server is using an invalid certificate: %s", reason.Error())
                }
        }
        var input bool
        if kterm.IsTerminal(reader) {
                if len(insecureTLSRequestReason) > 0 {
                        fmt.Fprintln(out, insecureTLSRequestReason)
                }
                fmt.Fprintln(out, "You can bypass the certificate check, but any data you send to the server could be intercepted by others.")
                input = term.PromptForBool(os.Stdin, out, "Use insecure connections? (y/n): ")
                fmt.Fprintln(out)
        }
        return input
}
===========================

To resolve this issue in 3.11, we need to update the cert in the default CA trust:

# cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust

Now after login into the cluster in 3.11  this time, it won't ask for the certificate.

 
Basically, the CA trust is not added in 3.11 by default in the trusted CA store. While this is added by default in OCP 3.7. 

This type of behaviour was observed since OCP 3.10 that is ,the installation of version 3.10 does not copy the internal openshift ca certificates to /etc/pki/ca-trust/source/anchors/  by default. 

Version-Release number of selected component (if applicable):
Openshift Container Platform 3.11

How reproducible:


Actual results:
the CA trust is not added in 3.11 by default in the trusted CA store. While this is added by default in OCP 3.7. 

Expected results:
The CA trust should be added in 3.11 by default in the trusted CA store, like 3.7




Additional info:

Comment 9 Joseph Callen 2019-08-14 20:19:05 UTC

*** This bug has been marked as a duplicate of bug 1713333 ***

Comment 14 Weihua Meng 2019-08-26 09:39:26 UTC
Fixed.

openshift-ansible-3.11.141-1.git.0.a7e91cd.el7

certificate deployed.

[root@ip-172-18-12-164 ~]# ll /etc/pki/ca-trust/source/anchors/
total 4
-rw-r--r--. 1 root root 1070 8月  26 03:32 openshift-ca.crt

and no certificate warning showed during login.

Comment 16 errata-xmlrpc 2019-09-03 15:56:02 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-2019:2580


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