Automate certificate management in OpenShift

September 24, 2025
Ajay Kanse
Related topics:
CI/CDContainersDeveloper ProductivityDevOpsDevSecOpsOperatorsPlatform engineeringSecurity
Related products:
Red Hat OpenShift GitOpsRed Hat OpenShift

In the world of modern IT, managing certificates is a constant challenge. For DevOps engineers, SREs, and IT managers working with a handful of clusters, it’s a manual effort that’s often time consuming. Without a standardized, automated process, application users might create certificates based on their preference, not on organizational guidelines, creating a major governance and security risk. The solution isn't to work faster. It's to automate. In this article, we’ll explore how to automate the entire certificate lifecycle in Red Hat OpenShift using the cert-manager operator for Red Hat OpenShift with Venafi, providing a secure and scalable solution for both platform and application certificates.

When you’re managing hundreds or even thousands of clusters, manual certificate management becomes a significant bottleneck. This approach is prone to human error, which can lead to certificate expirations, unexpected downtime, and an inconsistent security posture across your environments. A declarative, policy-driven approach to certificate management can ensure compliance, agility, and resilience in a dynamic hybrid cloud environment.

Disclaimer:

The cert-manager operator mentioned in the article is the Red Hat supported certificate manager operator. Ensure that IBM certificate manager operator doesn't exist in the cluster along with Red Hat certificate manager because both operators conflict with each other impacting functionality.

Also, the platform certificates in this article are mainly API certificate and Ingress certificate. It doesn't refer to any of the certificates used by the cluster internally for node-to-node or etcd communication.

Traditional vs. modern certificate management

Let's look at how certificate management has evolved, shifting from traditional to modern certificate management.

Traditional (past):

  • Manual request and download
  • CLI/Script-based
  • Time consuming renewals
  • Error prone
  • Ongoing support and maintenance

Modern (new):

  • Automated request
  • Declarative YAMLs
  • Auto-renewals via controller
  • Policy-driven and auditable
  • One-time setup and configuration

This new approach is about moving from a reactive, high-effort model to a proactive, low-maintenance one. It frees up your team from the manual, repetitive work and allows them to focus on innovation.

A deep dive into automated workflow

The cert-manager operator simplifies certificate management by natively integrating with OpenShift. It provides an automated lifecycle, from issuing to renewing certificates seamlessly. When combined with a robust external issuer like Venafi TPP, it provides enterprise-grade security and trust. The entire process is handled declaratively, which means all actions are logged and auditable.

Follow these steps to set up automated certificate management:

Step 1: Install the cert-manager operator

The first step is to install the cert-manager operator. You can find it in the OpenShift OperatorHub. The operator automatically creates two namespaces: cert-manager-operator and cert-manager. The operator and its controller resources will run in the cert-manager namespace, and all configuration and certificate resources will be created there.

Step 2: Create Venafi connection secret

You have to work with the Venafi team to setup Venafi TPP platform so that necessary permissions are granted for the service id and respective endpoints. Refer to the cert-manager documentation for more details.

We use the https://tpp.example.com/vedauth/authorize/oauth endpoint to generate the access token.

To allow cert-manager to communicate with Venafi TPP, you need to create a Kubernetes secret that stores the access token for authentication.

YAML:

apiVersion: v1
kind: Secret
metadata:
  name: venafi-tpp-secret
  namespace: cert-manager
type: Opaque
stringData:
  access-token: "YOUR-VENAFI-ACCESS-TOKEN"

Apply this secret to your cluster using oc apply -f <filename>.

Note: Enabling necessary Venafi TPP endpoint and RBAC for the service id and testing to make sure access is setup accurately took good amount of time for us.

Step 3: Create a ClusterIssuer with Venafi policies

The ClusterIssuer resource represents the certificate authority that will issue your certificates. In this case, it’s Venafi TPP, configured with the Venafi endpoint, the certificate policy zone, and a reference to the secret you created in the previous step.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: venafi-internal-1year
spec:
  venafi:
    tpp:
      cabundle: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
      url: https://venafi-tpp.example.com/VEDSDK
      credentialsRef:
        name: venafi-tpp-secret
      zone: "\VED\PolicyCertifiactes\cert-manager\Internal\1year"

Applying this YAML creates the ClusterIssuer. When the status becomes Ready: True, it's ready to issue certificates.

Step 4: Create a certificate resource

Now you can create a Certificate resource for your application or platform in a specific namespace. This resource tells cert-manager what certificate to request and where to store the resulting TLS secret. This approach makes it easy to provision certificates using Kubernetes-native resources.

The following example is for an OpenShift Ingress certificate, created in the openshift-ingress namespace.

This is wild card certificate for ingress controller and it is used for web console and CLI access.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: ocp-apps-cert
 namespace: openshift-ingress
spec:
 commonName: "*.apps.ocp.example.com".  # Wild card certificate
 dnsNames:
 - "*.apps.ocp.example.com"
 issuerRef:
   group: cert-manager.io
   name: venafi-internal-1year # Clusterissuer issuing certificate with	 
                               # 1 yr validity
   kind: ClusterIssuer
 privateKey:
   algorithm: RSA
   encoding: PKCS1
   size: 2048
 renewBefore: 360h0m0s           # Renewal period when certificate will be renewed
 secretName: ocp-app-cert-secret # Secret name that stored certiticate details

Note: The wild card certificates may have special policies to restrict its duration and require more frequent renewal.

The following certificate is for API server and it needs to be created in openshift-config namespace.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: ocp-api-cert
 namespace: openshift-config
spec:
 commonName: "api.ocp.example.com".  # Wild card certificate
 dnsNames:
 - "api.ocp.example.com"
 issuerRef:
   group: cert-manager.io
   name: venafi-internal-1year # Clusterissuer issuing certificate with	 
                               # 1 yr validity
   kind: ClusterIssuer
 privateKey:
   algorithm: RSA
   encoding: PKCS1
   size: 2048
 renewBefore: 360h0m0s           # Renewal period when certificate will be renewed
 secretName: ocp-api-cert-secret # Secret name that stored certiticate details

Once corresponding resources are applied, the cert-manager operator will communicate with Venafi TPP, issue the certificate, and store the TLS key and certificate in the ocp-app-cert-secret and ocp-api-cert-secret in the respective namespaces.

The certificate issued also provides certificate creation date/time, expiry date/time and renewal date/time as well. Certificate resource status will show status: True.

This example status details in the certificate resource:

status:
  conditions:
    - type: Ready
      status: "True"
      reason: Ready
      message: Certificate is up to date and has not expired
      lastTransitionTime: "2025-06-20T14:03:00Z"
  notAfter: "2025-10-09T15:40:41Z"
  notBefore: “2025-07-11T15:40:41Z”
  renewalTime: "2025-09-19T15:40:41Z"

Step 5: Patch the OpenShift certificates

With the new certificate secrets created, you can update the OpenShift API server and Ingress controller to use it.

  • The default IngressController in the namespace openshift-ingress-operator is patched with the secret ocp-app-cert-secret created in the openshift-ingress namespace.
  • The cluster APIServer resource is patched with the secret ocp-api-cert-secret created in the openshift-confignamespace.

Use the oc patch command to apply these newly created secrets:

# Patch the Ingress Controller
oc patch ingresscontroller.operator.openshift.io default \
--type=merge -p '{"spec":{"defaultCertificate":{"name":"ocp-app-cert-secret"}}}' \
                                                                    -n openshift-ingress-operator
# Patch the API Server
oc patch apiserver.operator.openshift.io cluster \
--type=merge -p '{"spec":{"servingCerts":{"namedCertificates":[{"names":["api.ocp.example.com"], "servingCertificate": {"name": "ocp-api-cert-secret"}}]}}}'

After patching, verify that the Ingress pods have restarted to picked up the new certificate, for API server verify new version of kube-apiserver ClusterOperator has been rolled out to all master nodes.

Refer to the documentation for more details on patching resources.

Additional ecosystem secures automation

When managing platform certificates, it's critical to ensure all components of the automation ecosystem function as expected. Failures in components, such as the cert-manager pods or the Venafi access token renewal process, can disrupt the entire workflow for issuing or renewing certificates, potentially causing platform downtime.

To address these issues and maintain the integrity of the automated system, we've implemented the following controls:

  • Proactive access token renewal: A cron job is set up to renew the Venafi access token every 15 days, well before its monthly expiration, to prevent disruptions.
  • Automated alerting: If the cron job for token renewal fails, a critical alert goes to the operations team to allow for immediate intervention, using alert manager.
  • Component monitoring: A Splunk alert configured to monitor the health of the cert-manager pods and report any failures directly to the operations team.
  • Enhanced visibility: A reporting UI developed to provide a clear view of all certificates, including their creation, expiry, and renewal date/time. This tool simplifies visibility and helps in tracking the status of all certificates across all clusters.
  • Smart notifications: The reporting tool automatically sends email notifications to certificate owners when renewal is due and sends an alert email if a renewal doesn't occur within the specified time.

Extending automation to applications

While cert-manager automates the certificate lifecycle, the challenge for application teams is ensuring the updating of their applications and services when issuing new certificate. Additionally, application pods don't automatically restart or reload when a referenced secret changes, often requiring a manual restart to pick up the renewed certificate. This is where community-supported operators can help.

Cert-Utils Operator project

The Cert-Utils Operator, a community-supported project, automates several key tasks for application teams. It works with certificates available as Kubernetes secrets, typically of type kubernetes.io/tls. One of its core functions is populating certificates on OpenShift routes. For routes with edge or re-encrypt termination, this operator uses an annotation to automatically update the route's TLS key and certificate when the underlying secret changes.

This functionality streamlines a process that would otherwise require manual intervention. The operator also provides other useful features, such as:

  • Java keystore/truststore creation: It can create Java Keystore and Truststore files from the certificates.
  • CA bundle injection: It can inject CA bundles into various Kubernetes objects like Secrets, ConfigMaps, and even CustomResourceDefinition objects.
  • Certificate expiration alerts: It can generate alerts when a certificate is about to expire.

These features activate via opt-in annotations on your resources.

Here are example annotations you can use:

cert-utils-operator.redhat-cop.io/certs-from-secret: "tls-secret"
cert-utils-operator.redhat-cop.io/destinationCA-from-secret: "tls-secret"

Reloader operator

The Reloader operator addresses the issue of manually restarting pods after a configuration change. It watches for changes to a ConfigMap or Secret and automatically performs a rolling update of associated workloads, such as deployments, DaemonSets, and StatefulSets.

When cert-manager issues a new certificate, it updates the secret. Reloader detects this change and initiates a rolling update of the pods that reference that secret, ensuring they are always using the latest certificate without any manual intervention. This is particularly useful for application and middleware teams, as it automates a critical step in the certificate renewal process. The operator also works based on annotations.

For example, to enable Reloader on a deployment that uses a secret named my-cert-secret, you would add the following annotation:

secret.reloader.stakater.com/reload: "my-cert-secret"

This operator has enterprise versions available that offer service level agreements (SLAs) and certified images for production environments.

Community operators

It's important to be transparent about the use of community-supported projects. While these operators are powerful and widely used, Red Hat does not provide direct support for them. Support is on a "best efforts" basis. However, their declarative, annotation-based approach aligns perfectly with the OpenShift operational model and significantly enhances your platform and application security posture.

Final thoughts

Automating certificate management with the cert-manager operator for Red Hat OpenShift and Venafi provides a secure and scalable solution that eliminates the risks and inefficiencies of manual processes. It centralizes control, ensures consistency, and allows your team to focus on innovation instead of repetitive, error-prone tasks. By leveraging the power of declarative configuration and OpenShift-native tools, you can build a more resilient and agile platform that scales with your organization.