Hide Forgot
Description of problem: openshift ex diagnostics errors about certificate when public URL is configured with custom cert. Version-Release number of selected component (if applicable): 3.1.1.6 How reproducible: 100% Steps to Reproduce: 1. Run installer, setting a different publicMasterURL and masterURL 2. After install add a custom serving certificate for the publicMasterURL 3. Run diagnostics Actual results: Error [1] Expected results: No Error Additional info: [1] ERROR: [DCli0006 from diagnostic ConfigContexts@openshift/origin/pkg/diagnostics/client/config_contexts.go:286] For client config context 'default/pulic-openshift-exampl-com:443/system:admin': The server URL is 'https://public-openshift.example.com:443' The user authentication is 'system:admin/pulic-openshift-exampl-com:443' The current project is 'default' (*url.Error) Get https:/public-openshift.example.com:443/api: x509: certificate signed by unknown authority This means that we cannot validate the certificate in use by the master API server, so we cannot securely communicate with it. Connections could be intercepted and your credentials stolen. Since the server certificate we see when connecting is not validated by public certificate authorities (CAs), you probably need to specify a certificate from a private CA to validate the connection. Your config may be specifying the wrong CA cert, or none, or there could actually be a man-in-the-middle attempting to intercept your connection. If you are unconcerned about any of this, you can add the --insecure-skip-tls-verify flag to bypass secure (TLS) verification, but this is risky and should not be necessary. ** Connections could be intercepted and your credentials stolen. **
What does your kubeconfig look like in the above scenario? The obvious explanation would be that your custom server cert wasn't signed by a trusted CA (at least, not trusted according to openshift on this host), as it says. But I think you would recognize that problem. Another explanation is that there are (at least) two contexts in your kubeconfig, one with a CA for the old cert, and one for the new cert/CA. Delete the old one and this error will go away. This diagnostic tests all the contexts in the config file, not just the current one.
Correct the CA does not match the context. The issue here with this bug is the question of this being the error when the current context is set to a valid user and cluster. The error suggests that something is wrong, when in fact its just checking an old context still in the kubeconfig.
Oh; alright. Yeah, I thought it would be useful to have it tell you about all your contexts (multiple users, multiple hostnames on the same cluster, etc) but I agree it probably doesn't merit an error if it's not for the current context. I already have a TODO to downgrade those to warnings. Would you like to use this bug to track that work?