This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1271983 - [platformmanagement_public_524]The custom certificate could not be served
[platformmanagement_public_524]The custom certificate could not be served
Status: CLOSED NOTABUG
Product: OpenShift Origin
Classification: Red Hat
Component: Auth (Show other bugs)
3.x
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Jordan Liggitt
weiwei jiang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-15 04:37 EDT by Wei Sun
Modified: 2015-12-14 10:59 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-15 23:52:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wei Sun 2015-10-15 04:37:09 EDT
Description of problem:
Added the custom certificate information to master-config.yaml,but the custom certificate could not be served when I access the web console or access the server via oc


Version-Release number of selected component (if applicable):
$ openshift version
openshift v1.0.6-328-gdf1f19e
kubernetes v1.1.0-alpha.1-653-g86b4e77


How reproducible:
Always

Steps to Reproduce:
1.Update the master-config as following:
servingInfo:
    bindAddress: 0.0.0.0:8443
    bindNetwork: tcp4
    certFile: master.server.crt
    clientCA: ""
    keyFile: master.server.key
    namedCertificates:
    - certFile: custom1.crt
      keyFile: custom1.key
      names:
      - "customhost.com"
    - certFile: custom2.crt
      keyFile: custom2.key
      names:
      - "*.anotherhost.com"

2.Start Openshift

3.Add customhost.com to /etc/hosts

$master_ip customhost.com

4.Access https://customhost.com:8443 and https://customhost.com:8443/swaggerapi/

5.Check the certificate information

6.Log in via oc
oc login --server=customhost.com:8443

7.Change "customhost.com" to "test.anotherhost.com"

8.Access https://test.anotherhost.com:8443

9.Check the certificate information

10.Log in via oc


Actual results:
5.The certificate is still CN = openshift-signer@1444876937

6.
$ oc login --server=customhost.com:8443
Unable to connect to the server: x509: certificate is valid for $my instance ip, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, localhost, openshift, openshift.default, openshift.default.svc, openshift.default.svc.cluster.local, 127.0.0.1, 172.17.42.1, 172.18.13.16, 172.30.0.1, not customhost.com

9.10 The custom certificate still is not served

Expected results:
The custom certificate should be served

Additional info:
Comment 1 Jordan Liggitt 2015-10-15 08:44:45 EDT
Are you setting "servingInfo.namedCertificates" or "assetConfig.servingInfo.namedCertificates"?

assetConfig.servingInfo.* is only used when assetConfig.servingInfo.bindAddress is different than servingInfo.bindAddress. When they are the same, the UI and API are served from the same port, and only the root servingInfo is used.
Comment 2 Wei Sun 2015-10-15 23:21:37 EDT
Checked this bug again.
Yesterday I set assetCofig.servingInfo.namedCertificates.
Today I set servingInfo.namedCertificates,but the custom certificate still could not be served.

servingInfo:
  bindAddress: 0.0.0.0:8443
  bindNetwork: tcp4
  certFile: master.server.crt
  clientCA: ca.crt
  keyFile: master.server.key
  namedCertificates:
  - certFile: custom1.crt
    keyFile: custom1.key
    names:
    - "customhost.com"
  - certFile: custom2.crt
    keyFile: custom2.key
    names:
    - "*.anotherhost.com"
  maxRequestsInFlight: 500
  namedCertificates: null
  requestTimeoutSeconds: 3600
                              

Check the custom certificate info:
# openssl x509 -in custom2.crt -noout -text|egrep -i "issue"
        Issuer: C=CH, ST=BJ, L=Default City, O=Default Company Ltd, CN=*.anotherhost.com

But the served certificate is:
CN = openshift-signer@1444963439
Comment 3 Jordan Liggitt 2015-10-15 23:51:18 EDT
Confirmed it was a configuration issue, moving to QA to verify/close
Comment 4 Wei Sun 2015-10-15 23:52:18 EDT
Checked this bug again,I remove "namedCertificates: null" , it works now.

The served certificate is my custom certifciate:

CN = *.anotherhost.com
O = Default Company Ltd
L = Default City
C = CH

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