Deploy non-self-signed TLS certificates for production usage

A typical reconfiguration scenario involves transitioning Obcerv Ingresses from using self-signed to non-self-signed TLS certificates before rolling out to production.

Before performing the steps below, it is assumed that you have already installed an Obcerv instance and configured it to use cert-manager to generate self-signed certificates.

  1. Confirm that your Ingresses are currently using self-signed certificates.

    Assuming your DNS names are set up as follows:

      externalHostname: www.obcerv.local
      externalHostname: ingestion.obcerv.local

    Run the following commands to verify that you are currently using self-signed certificates:

    %> curl -vk https://www.obcerv.local
    %> curl -vk https://www.obcerv.local/auth
    %> curl -vk https://ingestion.obcerv.local

    Check that the output contains lines similar to these:

    * Server certificate:
    *  subject: O=Acme Co; CN=Kubernetes Ingress Controller Fake Certificate
    *  start date: Apr  4 11:00:06 2023 GMT
    *  expire date: Apr  3 11:00:06 2024 GMT
    *  issuer: O=Acme Co; CN=Kubernetes Ingress Controller Fake Certificate
    *  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
  2. Create a new TLS secret of type

    %> kubectl create secret tls my-secret --cert=<full chain PEM file> --key=<private key PEM file> -n itrs
  3. Edit the configuration:

       selfSigned: false
       tlsSecret: my-secret
       tlsSecret: my-secret
  4. Back up existing objects:

    %> kubectl get certificate obcerv-ca -o yaml -n <namespace> > /path/to/backup/old-cert.yaml
    %> kubectl get secret -o yaml obcerv-ca -n <namespace> > /path/to/backup/old-ca.yaml
    %> kubectl get issuer -o yaml obcerv-issuer -n <namespace> > /path/to/backup/old-issuer.yaml
  5. Reconfigure:

    %> helm upgrade -n <namespace> -f obcerv.yaml obcerv itrs/obcerv --version <currently-installed-version>
  6. Check that new TLS certificate is in use:

    %> curl -vk https://www.obcerv.local
    %> curl -vk https://www.obcerv.local/auth
    %> curl -vk https://ingestion.obcerv.local

    The output should show a subject, expiration date, and issuer matching your TLS certificate.

  7. Delete the old self-signed CA secret used by the Web Console

    The obcerv-ca secret is created by the Obcerv Operator when installing using self-signed certificates and contains Obcerv’s full trust chain displayed by the Web Console in order to facilitate the connection of data sources (like Geneos) to Obcerv.

    That secret now contains outdated certificates and needs to be deleted before optionally being re-created (see next step).

    %> kubectl delete secret obcerv-ca -n <namespace>
  8. (Optional) Re-create the CA secret used by the Web Console:

    The obcerv-ca secret is useful if you need the Web Console to display Obcerv’s full trust chain to facilitate TLS connections to Obcerv.


    If you are connecting a Geneos Gateway to Obcerv, this is only required if none of the following applies:

    • The Gateway version is at least 6.1.0 and the Gateway is configured to skip the verification of the Obcerv certificate.
    • The Obcerv certificate is signed by a CA already trusted by the Gateway.

    First, recreate the obcerv-ca secret with the new chain:

    %> kubectl create secret generic obcerv-ca --from-file=<CA cert PEM file>=<full chain PEM file> -n <namespace>

    Then restart the Web Console to pick up the change:

    %> kubectl delete pod -n <namespace> obcerv-app-webconsole

    Wait for the Web Console pod to start, then log in and confirm that the new trust chain is displayed.

["Obcerv"] ["User Guide", "Technical Reference"]

Was this topic helpful?