Post cover image

September 4, 2026

Red Hat Cert-Manager with Custom CA

In this lab, I want OpenShift to use certificates signed by my own Custom CA.

By Fabio Reis

5 min read

This runbook shows how to use cert-manager and a Custom CA to manage TLS certificates for an OpenShift lab.

The configuration covers:

  • The OpenShift API
  • The default application domain
  • The OAuth endpoint used by oc login
  • The default OpenShift Console route
  • Application Routes

The endpoints are:

API: api.ocp.example.com
OAuth: oauth-openshift.apps.ocp.example.com
Console: console-openshift-console.apps.ocp.example.com
Apps: *.apps.ocp.example.com

This lab stores the Custom CA private key in an OpenShift Secret. This is acceptable for a lab or a CA dedicated to one cluster. A corporate root CA private key should never be stored in the cluster.

Prerequirements

Before starting, make sure you have:

  • An OpenShift cluster.
  • The Red Hat build of cert-manager installed from OperatorHub.
  • oc logged in as a cluster administrator.
  • DNS records for the API, Console, and Apps domains.
  • OpenSSL available on your workstation.

Operator :

None

Check cert-manager:

oc get pods -n cert-manager
oc get crd | grep cert-manager.io

If your cert-manager installation uses another namespace, replace cert-manager in the commands below.

1. Create a Custom CA

A CA Issuer needs a certificate and private key. In this lab, I will create a simple self-signed CA to simulate a site which uses a internal CA.

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -nodes \
  -key lab-ca.key \
  -sha256 \
  -days 3650 \
  -out lab-ca.crt \
  -subj "/CN=OpenShift Lab Custom CA/O=Lab"

This creates:

lab-ca.crt
lab-ca.key

Now create a TLS Secret in the cert-manager namespace:

oc -n cert-manager create secret tls cluster-custom-ca \
  --cert=lab-ca.crt \
  --key=lab-ca.key

Check the Secret:

oc get secret cluster-custom-ca -n cert-manager

2. Create the ClusterIssuer

The ClusterIssuer allows cert-manager to use this CA from any namespace.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cluster-custom-ca
spec:
  ca:
    secretName: cluster-custom-ca

Apply it:

oc apply -f cluster-custom-ca-issuer.yaml

Validate it:

oc get clusterissuer cluster-custom-ca

Expected result:

NAME                READY   AGE
cluster-custom-ca   True    1m

3. Create the API certificate

The API Server expects the generated TLS Secret in openshift-config.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-serving-cert
  namespace: openshift-config
spec:
  secretName: api-serving-cert
  duration: 2160h
  renewBefore: 360h
  issuerRef:
    name: cluster-custom-ca
    kind: ClusterIssuer
  dnsNames:
    - api.ocp.example.com

Apply it and wait for the certificate:

oc apply -f api-serving-cert.yaml
oc get certificate api-serving-cert \
  -n openshift-config -w

The expected result is:

NAME               READY   SECRET             AGE
api-serving-cert   True    api-serving-cert   1m

4. Configure the API Server

First, check whether the cluster already has named API certificates:

oc get apiserver cluster \
  -o jsonpath='{.spec.servingCerts.namedCertificates}{"\n"}'

For a lab without existing named certificates, configure the API Server with this patch:

oc patch apiserver cluster \
  --type=merge \
  -p '{
    "spec": {
      "servingCerts": {
        "namedCertificates": [
          {
            "names": [
              "api.ocp.example.com"
            ],
            "servingCertificate": {
              "name": "api-serving-cert"
            }
          }
        ]
      }
    }
  }'

The patch replaces the complete namedCertificates list. If entries already exist, use oc edit apiserver cluster and append the new certificate instead.

Check the API Server Operator:

oc get co kube-apiserver

Validate the certificate served by the API:

openssl s_client \
  -connect api.ocp.example.com:6443 \
  -servername api.ocp.example.com \
  -CAfile lab-ca.crt </dev/null

Expected result:

issuer=CN=OpenShift Lab Custom CA, O=Lab
Verify return code: 0 (ok)

5. Create the wildcard certificate for Apps

The default Ingress Controller expects its TLS Secret in openshift-ingress.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: apps-wildcard-cert
  namespace: openshift-ingress
spec:
  secretName: apps-wildcard-cert
  duration: 2160h
  renewBefore: 360h
  issuerRef:
    name: cluster-custom-ca
    kind: ClusterIssuer
  dnsNames:
    - "*.apps.ocp.example.com"

Apply it and wait for readiness:

oc apply -f apps-wildcard-cert.yaml
oc get certificate apps-wildcard-cert \
  -n openshift-ingress -w

Trust the Custom CA inside OpenShift

The Authentication Operator validates the OAuth Route through the default Ingress Controller. Before configuring a Custom CA-signed certificate on the router, add the CA certificate to the OpenShift trust bundle.

Extract the Root CA created by cert-manager:

oc -n cert-manager get secret cluster-custom-ca \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > lab-ca.crt

Create the Custom CA ConfigMap:

oc -n openshift-config create configmap custom-ca \
  --from-file=ca-bundle.crt=lab-ca.crt

Associate it with the cluster Proxy configuration:

oc patch proxy cluster \
  --type=merge \
  -p '{"spec":{"trustedCA":{"name":"custom-ca"}}}'

Validate the configuration:

oc get proxy cluster \
  -o jsonpath='{.spec.trustedCA.name}{"\n"}'

Expected output:

custom-ca

6. Configure the default Ingress Controller

Patch only the default certificate field, preserving the existing Ingress Controller configuration:

oc patch ingresscontroller default \
  -n openshift-ingress-operator \
  --type=merge \
  -p '{"spec":{"defaultCertificate":{"name":"apps-wildcard-cert"}}}'

Confirm the configured Secret:

oc get ingresscontroller default \
  -n openshift-ingress-operator \
  -o jsonpath='{.spec.defaultCertificate.name}{"\n"}'

Expected result:

apps-wildcard-cert

The router automatically observes the Secret. A manual router restart is not required.

7. Validate OAuth, Console, and application Routes

The OAuth endpoint is especially important because oc login is redirected to it after contacting the API.

Check the OAuth Route hostname:

oc get route oauth-openshift \
  -n openshift-authentication \
  -o jsonpath='{.spec.host}{"\n"}'

Validate its certificate:

openssl s_client \
  -connect oauth-openshift.apps.ocp.example.com:443 \
  -servername oauth-openshift.apps.ocp.example.com \
  -CAfile lab-ca.crt </dev/null

Validate the Console:

openssl s_client \
  -connect console-openshift-console.apps.ocp.example.com:443 \
  -servername console-openshift-console.apps.ocp.example.com \
  -CAfile lab-ca.crt </dev/null

Validate an application Route:

openssl s_client \
  -connect myapp.apps.ocp.example.com:443 \
  -servername myapp.apps.ocp.example.com \
  -CAfile lab-ca.crt </dev/null

All three checks should return:

issuer=CN=OpenShift Lab Custom CA, O=Lab
Verify return code: 0 (ok)

8. Trust the Custom CA on the workstation

On RHEL, Fedora, or CentOS, add the Custom CA to the system trust store:

sudo cp -v lab-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

For an explicit and reproducible login, pass the CA file directly:

oc login \
  --certificate-authority="$PWD/lab-ca.crt" \
  --server=https://api.ocp.example.com:6443 \
  -u kubeadmin

The resulting kubeconfig entry stores the CA data for this cluster.

Troubleshooting

The API certificate is valid, but oc login fails

A common error is:

tls: failed to verify certificate: x509: certificate signed by unknown authority

Validate the API first:

openssl s_client \
  -connect api.ocp.example.com:6443 \
  -servername api.ocp.example.com \
  -CAfile lab-ca.crt </dev/null

If the API returns:

Verify return code: 0 (ok)

but oc login still fails, validate the OAuth Route:

openssl s_client \
  -connect oauth-openshift.apps.ocp.example.com:443 \
  -servername oauth-openshift.apps.ocp.example.com \
  -CAfile lab-ca.crt </dev/null

If the issuer is similar to this:

issuer=CN=ingress-operator@...

and the output contains:

Verify return code: 19 (self-signed certificate in certificate chain)

the default Ingress Controller is still using the OpenShift-generated certificate.

Create the wildcard certificate and apply the Ingress Controller patch described in steps 5 and 6.

Confirm that the API certificate uses the expected CA

Extract the certificate served by the API:

openssl s_client \
  -connect api.ocp.example.com:6443 \
  -servername api.ocp.example.com \
  -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{p=1} p{print} /END CERTIFICATE/{exit}' \
  > server-api.crt

Validate it:

openssl verify -CAfile lab-ca.crt server-api.crt

Expected output:

server-api.crt: OK

Check cert-manager resources

oc get clusterissuer
oc get certificate -A
oc get certificaterequest -A

Inspect a failed Certificate resource:

oc describe certificate api-serving-cert \
  -n openshift-config

Final result

cert-manager now manages the certificate lifecycle for the OpenShift API and default application domain.

Custom CA
    ↓
cert-manager ClusterIssuer
    ↓
TLS Secrets
    ├── openshift-config / api-serving-cert
    └── openshift-ingress / apps-wildcard-cert
             ↓
OpenShift API, OAuth, Console, and application Routes

The API, OAuth endpoint, Console, and application Routes use certificates signed by the same Custom CA. Certificates are declared as Kubernetes resources, renewed by cert-manager, and consumed by the appropriate OpenShift Operators.