[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: namedCertificates not working



I tried but same error from curl or OC client.

 

Browser showing green lock with right cert info but not displaying any projects including defaults projects.

 

Am seeing below errors from master

 

sudo journalctl -xe -u atomic-openshift-master-api.service

 

Nov 15 22:47:36 cae-ga3-1 atomic-openshift-master-api[117557]: I1115 22:47:36.754142  117557 server.go:2161] http: TLS handshake error from 64.101.6.3:33138

Nov 15 22:47:36 cae-ga3-1 atomic-openshift-master-api[117557]: I1115 22:47:36.755929  117557 server.go:2161] http: TLS handshake error from 64.101.6.3:33140

Nov 15 22:47:36 cae-ga3-1 atomic-openshift-master-api[117557]: I1115 22:47:36.756570  117557 server.go:2161] http: TLS handshake error from 64.101.6.3:33142

lines 952-1001/1001 (END)

 

 

-- 

Srinivas Kotaru

 

From: Jordan Liggitt <jliggitt redhat com>
Date: Tuesday, November 15, 2016 at 2:41 PM
To: Srinivas Naga Kotaru <skotaru cisco com>
Cc: dev <dev lists openshift redhat com>
Subject: Re: namedCertificates not working

 

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

 

 

 


On Nov 15, 2016, at 5:30 PM, Srinivas Naga Kotaru (skotaru) <skotaru cisco com> wrote:

Trying to deploy prod grade cert to our prod installation.   Browser showing green light but CLI clients showing cert errors.  OC client unable to display any projects. Do we need to use cafile in the config? I couldn’t find right syntax . I tried caFile but no use.

 

Although browser showing green light and showing correct cert info, unable to display any projects including default projects after authentication

 

We are using separate URL for public and internal OpenShift communication. Public URL is load balanced with 3 masters. LB was configured with SS pass-through to masters and masters doing actual SSL offload.

 

oc login https://<API VIP> 1

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):

 

oc project default                                                                                                           1

Error from server: Get https://<api vip> /api/v1/namespaces/default: x509: certificate signed by unknown authority

 

assetConfig:

  logoutURL: ""

  masterPublicURL: https://apivip

  publicURL: https://apivip/console/

  servingInfo:

    bindAddress: 0.0.0.0:443

    bindNetwork: tcp4

    certFile: master.server.crt

    clientCA: ""

    keyFile: master.server.key

    maxRequestsInFlight: 0

    requestTimeoutSeconds: 0

    namedCertificates:

      - certFile: /opt/cae/certs/master/cae.crt

        keyFile: /opt/cae/certs/master/cae.key

names:

          - "mastervip"

          - "master1"

         - "master2"

          - "master3"

 

servingInfo:

  bindAddress: 0.0.0.0:443

  bindNetwork: tcp4

  certFile: master.server.crt

  clientCA: ca.crt

  keyFile: master.server.key

  maxRequestsInFlight: 500

  requestTimeoutSeconds: 3600

  namedCertificates:

    - certFile: /opt/cae/certs/master/cae.crt

      keyFile: /opt/cae/certs/master/cae.key

names:

          - "mastervip"

          - "master1"

         - "master2"

          - "master3"

 

 

-- 

Srinivas Kotaru

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]