Openshift-ansible: Provide a mechanism to customise the registry console certificate and URL

Created on 6 May 2018  路  19Comments  路  Source: openshift/openshift-ansible

Description

According to the documentation at https://docs.openshift.org/3.9/install_config/install/advanced_install.html#advanced-install-configuring-registry-console, there is no way to customise the registry console installation at the initial installation (deploy_cluster.yml). To use a custom hostname and a valid certificate, I need to re-deploy it according to https://docs.openshift.org/3.9/install_config/install/advanced_install.html#advanced-install-configuring-registry-console.

I suggest adding a few variables so that it is possible to set the hostname and certificates at the first-time cluster installation time.

Version
openshift-ansible-3.9.27-1-43-g81cd65e6b
Steps To Reproduce
  1. Install an OpenShift Origin cluster including the registry console as described in https://docs.openshift.org/3.9/install_config/install/advanced_install.html#advanced-install-configuring-registry-console
  2. Navigate to https://registry-console-default.apps.your.domain/
  3. See that the TLS certificate is a self-signed certificate
Expected Results

I'd expect a non-self-signed TLS certificate that I can configure in my inventory, similar to openshift_hosted_registry_routecertificates. And I'd expect a nicer hostname like registry-console or registry-cockpit instead of registry-console-default.

Example command and output or error messages
Observed Results

A self-signed certificate is presented at a not so nice URL, https://registry-console-default.apps.your.domain/

Additional Information

I use a single certificate that is valid for my.domain, *.my.domain and *.apps.my.domain. So I configured the names parameter appropriately in the locations where I use this certificate: openshift_hosted_registry_routecertificates, openshift_hosted_router_certificate and openshift_master_named_certificates. At openshift_hosted_registry_routecertificates, it was at registry.apps.my.domain. Now I added registry-console-default.apps.my.domain to the list and re-ran deploy_cluster.yml, but it didn't change a thing.

lifecyclrotten

All 19 comments

i have also same issue

+1

+1

+1

+1. Yes, please fix.

Is there a reason why this shouldn't be possible with the console? Please fix.

There is also an issue that in providing a third-party signed certificate for the docker-registry, you can't get a third party to do *.local domains. So when we stand up a "stand-alone" registry, it is using a self-signed certificate, which puts us in a situation where we need to configure docker clients to see it as an insecure registry. We'd like to be able to fix that too.

Did anyone find a way to get this working? I am trying to configure a trusted ssl at registry console route without any luck.

After mocking around different configs of cockpit, I was able to configure a trusted cert using passthrough on registry console using the below steps.

After looking at cockpit https configs at https://cockpit-project.org/guide/latest/https.html#https-certificates I created a cert file with cert,intermediate ca, root ca, key in one single file named it as registry-console.cert
Added it as a secret and mounted it on registry-console.

oc create secret generic registry-console-cert \
--from-file=/etc/secrets/registry-console.cert

oc secrets link default registry-console-cert

oc set volume dc/registry-console --add --type=secret --secret-name=registry-console-cert -m /etc/cockpit/ws-certs.d

@dinusubba thanks for providing information ^^. I tried the steps you mentioned but i am getting An error occurred during a connection to registry-console-default.xxx.com. Peer鈥檚 certificate has an invalid signature. Error code: SEC_ERROR_BAD_SIGNATURE#. I am using let's encrypt certificates(privkey.pem,fullchain.pem), i tried to combine them in a file and rename it into registry-console.cert. Is this the correct way or i need to convert them?

@dinusubba thanks for providing information ^^. I tried the steps you mentioned but i am getting An error occurred during a connection to registry-console-default.xxx.com. Peer鈥檚 certificate has an invalid signature. Error code: SEC_ERROR_BAD_SIGNATURE#. I am using let's encrypt certificates(privkey.pem,fullchain.pem), i tried to combine them in a file and rename it into registry-console.cert. Is this the correct way or i need to convert them?

Hi @uocxp , the error might be related to the contents of cert file not in order in which it is expecting. Please try structuring your cert file as below.

The cert you attach must end in .cert and be in pem format with both the certificate and private key. The file should first have one or more BEGIN CERTIFICATE blocks for the server certificate and the intermediate certificate authorities and a last one containing a BEGIN PRIVATE KEY or similar.

So the registry-console.cert file I am using looks like this

-----BEGIN CERTIFICATE-----
Cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root CA
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Private key
-----END RSA PRIVATE KEY-----

@dinusubba I'm performing the steps you have quoted above but repeatedly get the error:

Failed to generate certificates exit status 1 remotectl: No certificate found in dir: /etc/cockpit/ws-certs.d

I have a file called registry-console.cert which contains my signed cert, intermediate, root and private key in that order. The certs are of type EC instead of RCA. I can't see if this could be an issue anywhere, is it something you have come across?

Edit: looks like Cockpit doesn't support EC. https://github.com/cockpit-project/cockpit/blob/1d03fa966b9c1b33a3fbe22b2aa4d75e65d936c5/src/ws/cockpitcertificate.c#L454

I'm also trying to get registry-console (cockpit) access via a Route but with no success.
OSE Router has been successfully configured with a default LetsEncrypt *.MYDOMAIN certificate, and all routes (except for the registry passthrough-ones) work flawlessly.

Editing the registry-console route with edge termination at first tells me _"Disconnected - Server has closed the connection."_ (but with the correct TLS certificate), and pressing the _"reconnect"_ button leads to a loop of 301 redirects from https://registry-console-default.MYDOMAIN/registry to itself.

With reencrypt, https://registry-console-default.MYDOMAIN/registry returns 503 with the standard _"Application is not available"_ page (served with the correct TLS certificate), and the cockpit pod logs
MESSAGE: cockpit-protocol: couldn't read from connection: Peer sent fatal TLS alert: CA is unknown

BTW, HAProxy logs are empty.

Some considerations:

  • cockpit uses websockets
  • cockpit listens both HTTP and HTTPS on 9090
  • reencrypt termination could be tweaked by spec.tls.destinationCACertificate

Any idea/solution how to allow custom certificate and re-encrypt? still 503 error code in okd 3.11...

OK I did it using the trick with a secret containing cert, key and a whole ca chain. After mounting such secret under /etc/cockpit/ws-certs.d path it started to work. Router has https enabled in pass-through mode. What is interesting it does not work properly in Opera browser - cert is not trusted there and console shows blank screen after logging in. It works very well in Firefox and Chrome. I used latest versions of browsers for this test.

it is a shame

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Was this page helpful?
0 / 5 - 0 ratings