Feature Overview

A number of platform certificates have currently a validity of up to 10 years (e.g. kube-apiserver-lb-signer). While this reduces management and potential disruption during rotation, some customers have policies in place requiring that any used certificate is 2 years or less for increased security.

Additionally these long-lived certificates are not customizable and do not extend their validity with cluster upgrades. This could create a scenario where a cluster could become entirely unavailable after a decade.

We are working on ensuring that rotations are 100% non-disruptive (OCPSTRAT-1797), which is a requirement before we can reduce the lifespan of platform certificates.

Related to this, we have simplified the shutdown and restore (hibernation) with recovery from Expired Certificates (OCPSTRAT-1103), another milestone towards this goal.

This feature, must be done in phased fashion, initially reducing the lifespan to 5 years (phase 1) followed by a further reduction to a lifespan of 2 years (phase 2).

Why is this important?

The sheer number of platform certificates across multiple components makes it nearly impossible for customers to manually list and track every certificate and its expiration date. This complexity needs a common, component-wide strategy to handle certificate expiration systematically, rather than addressing issues on a case-by-case basis.

Establishing a robust, unified process for certificate lifecycle management is essential to prevent future service outages and provide customers with the confidence they require in the platform's long-term stability.