Outcome Overview

This outcome builds upon the foundation established in OCPSTRAT-714 to ensure OpenShift provides comprehensive confidence to users in the way certificates are automatically managed and rotated. A core principle of OpenShift is that platform certificates should be managed entirely by the platform, with full transparency and automated lifecycle management.

This outcome addresses some gaps in certificate management including:

• Evaluating external certificate authority requirements for regulated environments (OCPSTRAT-2029)
• Reducing certificate validity periods to meet customer security policies (OCPSTRAT-2272, OCPSTRAT-2273)
• Enabling customizable RSA key sizes for compliance requirements (OCPSTRAT-2271)
• Providing manual rotation capabilities for long-lived certificates (OCPSTRAT-1826)
• Delivering visibility into certificate rotation schedules for security auditing (OCPSTRAT-1990).

Platform certificates must provide their "owning component" forming a registry available at https://github.com/openshift/origin/blob/main/tls/ownership/ownership.md, which includes components and operators annotated with "Owning Component" indicating proper rotation management. While this was part of the outcome of OCPSTRAT-714, these enhancements aim to provide more visibility and better management.

Why is this important?

The sheer number of platform certificates across multiple OpenShift components makes it nearly impossible for customers to manually track every platform certificate and its expiration date. Many organizations, particularly in financial services, healthcare, government, and telecommunications sectors, have stringent security policies requiring certificates with validity periods of 2 years or less. 

Additionally, long-lived certificates (currently 10-year validity) are not customizable and do not extend their validity with cluster upgrades, creating a scenario where clusters could become unavailable after a decade without manual rotation. 

While OpenShift has established a robust, unified process for certificate lifecycle management, we must provide customers with the confidence they require in the platform's long-term stability and compliance, and ensure that OpenShift remains competitive in highly regulated markets where certificate management is a compliance requirement.

Success Criteria

• Certificates never expire in production environments and automatic rotation occurs with sufficient lead time before expiration.
• Platform certificate validity periods meet customer security policy requirements, with all certificates defaulting to 2 years or less validity (phased implementation: 5 years in phase 1, 2 years in phase 2).
• Customers can customize certificate attributes including RSA key size (supporting up to 4096 bits for root CAs) to meet their compliance requirements.
• External certificate authority integration is evaluated and implementation paths are defined for regulated environments (Telco CMPv2, NSA Type 1, ANSSI, EU Cybersecurity Act compliance).
• Users can query platform certificate rotation information through APIs or CLI commands, including expiration dates, renewal schedules, and rotation history.
• Manual rotation capabilities exist and are tested via CI for long-lived certificates, without service disruption.