LEARN. PRACTICE. GROW.Concept and mechanism
Operational renewal includes more than obtaining a new certificate. Material must be distributed, certificate/key matching preserved, and the process made to load the correct version. If the application reads only at startup, updating a Secret does not prove activation. Use the supported reload or controlled restart mechanism and observe the endpoint afterward. Distribution across instances requires checking those that can receive traffic; one success at the virtual address may have reached only an updated node. Preserve capacity during change and define recovery criteria for failed activation. A repository file expresses configuration intent rather than sufficient execution evidence.
Guided application
Scheduling should use actually issued validity. In the cert-manager example without overrides, two thirds of 90 days is day 60, leaving 30 days of margin; this does not establish a universal certificate lifetime. Options and behavior depend on installed version. Maintain an inventory of endpoints, names, owners, and consumers, including dedicated trust stores. Observe expiry of served material and route alerts to someone able to act. In a fictional case, three pods load the new pair while the fourth retains the old one. The action is to complete activation in that process and validate, rather than repeatedly issue certificates it still does not read.
Updated Secret, old process state: issuance completed, but operational change did not.
Common pitfalls
Automation as absence of failures; issuance as reload; one instance as every instance; requested duration as actual duration.
Related topics: Keys, certificates, and trust · Identity, name, and time · Negotiation, mTLS, and the application
Establish the certificate actually presented by each relevant instance.
Reference: cert-manager Certificate lifecycle · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics