Issue got fixed. Am using a SAN cert and included individual master names also in the cert. I also included these individual master names in the configuration under names:
after removing individual master names issue got fixed. Now configuration has just public URL
able to see projects in the browser and CLI after authentication.
However CURL and OC clients sill throwing warning and not trusting certificate
oc login https://masterpublicurl
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):
Any idea why? Althoght it is prod grade cert from well known CA.
Nov 15 23:03:53 atomic-openshift-master-api: E1115 23:03:53.196173 121472 reflector.go:203] github.com/openshift/origin/pkg/project/auth/cache.go:188: Failed to list *api.Namespace: Get https://<api_server> /api/v1/namespaces?resourceVersion=0: x509: certificate signed by unknown authority
Nov 15 23:03:53 atomic-openshift-master-api: I1115 23:03:53.204024 121472 server.go:2161] http: TLS handshake error from 22.214.171.124:42824: remote error: bad certificate
Am wondering why this error sicne cert is fully valid. In fact, master console clearely showing green lock with right cert information.
Are you seeing this from a system where you previously logged in to that URL using oc with the non-prod CA bundle? When configured to use a non-system-roots ca bundle, oc remembers it in the local user's kubeconfig file ($KUBECONFIG or ~/.kube/config).
Try moving (or removing) the kubeconfig file and see if that allows oc to use the system roots to recognize the new certificates