Chapter 5. Certificate Management
5.1. Overview
Over the lifetime of a OpenShift Container Platform cluster, certificates will enter various phases of their lifecycle. The following procedures describe how to manage various parts of that lifecycle.
5.2. Changing An Application’s Self-signed Certificate to CA-signed Certificate
Some application templates create a self-signed certificate that is then directly presented by the application to clients. As an example, by default and as part of the OpenShift Container Platform Ansible installer deployment process, the metrics deployer creates self-signed certificates.
These self-signed certificates are not recognized by browsers. To mitigate this issue, use a publicly signed certificate, then configure it to re-encrypt traffic with the self-signed certificate.
Delete the existing route:
$ oc delete route hawkular-metrics -n openshift-infra
With the route deleted, the certificates that will be used in the new route with the re-encrypt strategy must be assembled from the existing wildcard and self-signed certificates created by the metrics deployer. The following certificates must be available:
- Wildcard CA certificate
- Wildcard private key
- Wildcard certificate
Hawkular CA certificate
Each certificate must be available as a file on the file system for the new route.
You can retrieve the Hawkular CA and store it in a file by executing the following command:
$ oc get secrets hawkular-metrics-certificate -n openshift-infra \ -o jsonpath='{.data.hawkular-metrics-ca\.certificate}' | base64 -d > hawkular-internal-ca.crt
- Locate the wildcard private key, certificate, and CA certificate. Place each into a separate file, such as wildcard.key, wildcard.crt, and wildcard.ca.
Create the new re-encrypt route:
$ oc create route reencrypt hawkular-metrics-reencrypt \ -n openshift-infra \ --hostname hawkular-metrics.ocp.example.com \ --key wildcard.key \ --cert wildcard.crt \ --ca-cert wildcard.ca \ --service hawkular-metrics \ --dest-ca-cert hawkular-internal-ca.crt
