Deploy non-self-signed TLS certificates for production usage

Important

This information refers to the previous helm install method for the Obcerv Platform. If you are looking to install using the more streamlined Kubernetes Off-the-Shelf (KOTS) method, see the updated installation overview.

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:

   apps:
     externalHostname: www.obcerv.local
   ingestion:
     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 kubernetes.io/tls:

   %> kubectl create secret tls my-secret --cert=<full chain PEM file> --key=<private key PEM file> -n itrs
   

3. Edit the configuration:

   tls:
   external:
      selfSigned: false
   apps:
   ingress:
      tlsSecret: my-secret
   ingestion:
   ingress:
      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.

   Note

   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.