As TLS certificate lifetimes shorten, Certificate Lifecycle Management is shifting from periodic maintenance to a continuous process that requires automation.
In modern IT environments, TLS certificates secure communication and authenticate applications, APIs, internal services, Kubernetes workloads, databases, and infrastructure components. These certificates are a critical part of a broader machine identity ecosystem, where every workload, service, and system must be securely identified and managed. To better understand this broader concept, read our guide, Machine Identity Lifecycle Management Explained.
Manual certificate management increases operational risk, particularly in large environments where thousands of certificates must be tracked, renewed, and replaced across multiple systems.
A proper Certificate Lifecycle Management process ensures that certificates are:
- Issued according to security policies
- Installed on the correct systems
- Renewed before expiration
- Monitored continuously
- Replaced quickly when compromised or no longer required
The challenge is not only issuing certificates but ensuring that their complete lifecycle is controlled and automated.
Why TLS Certificate Automation Is Becoming Essential
TLS certificate validity periods are becoming shorter. The industry is moving from yearly certificate renewal cycles toward significantly shorter lifetimes:
- 398 days before March 15, 2026
- 200 days from March 15, 2026
- 100 days from March 15, 2027
- 47 days from March 15, 2029
Shorter certificate lifetimes enhance security by mitigating the impact of compromised certificates and facilitating the faster adoption of stronger cryptographic standards.
However, they also introduce operational challenges. Organizations need to know:
- Where certificates are used
- Who owns them
- How are they renewed?
- How they are deployed
- How failures are detected
Without automation, certificate renewal becomes a repetitive manual process that increases administrative workload and the risk of service outages caused by expired certificates.
Certificate Lifecycle Management in Kubernetes
Kubernetes and OpenShift environments make certificate management even more dynamic. Applications are frequently created, updated, scaled, and removed. Certificates need to follow the same lifecycle as the applications they protect.
A Kubernetes-native approach enables certificates to be requested, issued, renewed, and managed automatically using tools such as cert-manager. However, enterprises often also require centralized governance, auditing, policy enforcement, and certificate inventory.
Certificates are renewed automatically before they expire, eliminating the need for administrators to monitor expiration dates or manage renewals manually.
Our Installation: Automating Certificate Lifecycle Management in OpenShift
To test this approach in practice, we created a Proof of Concept integrating:
- OpenShift Container Platform
- cert-manager
- CyberArk Trust Protection Platform (formerly Venafi Trust Protection Platform)
- EJBCA Community Edition
The goal was to automate the complete certificate workflow while keeping centralized control over certificate policies and issuance.
In this setup, cert-manager automates certificate requests and renewals within Kubernetes, CyberArk enforces certificate governance and lifecycle policies, and EJBCA acts as the Certificate Authority that issues and signs the certificates.
Certificate Request and Issuance Workflow
When an application exposed through an OpenShift Route requires HTTPS, a certificate request is created through cert-manager.
The configured venafi-clusterissuer ClusterIssuer defines how cert-manager communicates with CyberArk Trust Protection Platform. Authentication credentials are stored securely in a Kubernetes Secret, such as venafi-tpp-secret, which cert-manager uses to authenticate during certificate issuance and renewal operations.
The request is then processed by CyberArk, which applies predefined policies such as:
- Approved certificate templates
- Allowed domains
- Key requirements
- Certificate validity settings
- Approval rules
After the request passes validation, CyberArk forwards it to EJBCA Community Edition, which issues and signs the certificate.
The issued certificate is then returned through CyberArk to cert-manager, which stores it in a Kubernetes TLS Secret.
Certificate Deployment in OpenShift
Once the certificate is stored in the Kubernetes Secret, it can be used by an OpenShift Route for TLS termination.
The application does not manage certificates directly. Cert-manager updates the Kubernetes Secret with the renewed certificate, and OpenShift uses the updated certificate for HTTPS traffic.
This removes manual steps such as:
- Generating certificate requests
- Downloading certificates
- Updating application configurations
- Restarting services after renewal
Automated Renewal
The main benefit of the solution is that the lifecycle continues after the initial certificate issuance.
cert-manager monitors certificate expiration and automatically starts renewal before the certificate becomes invalid. The same validation and issuance process is repeated:
- cert-manager requests renewal
- CyberArk validates the request.
- EJBCA issues the replacement certificate
- cert-manager updates the Kubernetes Secret
Once configured, cert-manager monitors certificate validity and automatically requests a new certificate before the current one expires, preventing service disruptions caused by expired certificates and eliminating the need for manual renewal tracking.
Results and Benefits
The Proof of Concept demonstrated that OpenShift certificate management can be fully automated while maintaining enterprise security controls.
The main benefits were:
- Automated certificate provisioning
- Centralized certificate visibility and governance
- Policy-based issuance
- Automatic renewal and rotation
- Reduced risk of certificate expiration outages
- Less operational effort for application teams
Conclusion
The Proof of Concept was a successful demonstration of how OpenShift can be integrated with enterprise Certificate Lifecycle Management solutions.
Combining OpenShift, cert-manager, CyberArk Trust Protection Platform, and EJBCA Community Edition enabled an automated certificate workflow that maintains security and compliance requirements.
As certificate lifetimes continue to shorten, automation is becoming essential for modern application platforms. Based on the successful results of this PoC, we recommend adopting this solution as the standard approach for automated TLS certificate management in future OpenShift implementations.
Don’t let expired certificates cause your next outage. We help organizations implement automated Certificate Lifecycle Management for OpenShift, improving security, reliability, and operational control.
