In IBM Software Hub TLS certificates play a pivotal role in securing inter-pod communications. When one pod initiates a request to another, the receiving pod presents its TLS certificate, which the calling pod uses to authenticate the connection. This process ensures that only trusted services can interact within the cluster. During the installation of Software Hub and some associated services, TLS certificates are generated. From these certificates, a Kubernetes Secret is created and mounted into the services’ pods. This Secret contains the self-signed Certificate Authority (CA) certificate, ca.crt, which is essential for verifying outgoing requests to pods presenting that Certificate. Some services create their own certificates for communication and others use Software Hub's central certificate. Once created, the certificates lifecycle is handled by Red Hat Certificate Manager. 

From Renewal to Disruption: The Hidden Complexity of TLS Lifecycle Management in OpenShift

TLS certificates have a predefined expiration date, typically set during their creation. Red Hat Certificate Manager monitors the certificate's lifecycle and initiates an automatic renewal process when the certificate reaches approximately 70% of its validity period. This renewal involves regenerating the associated secret and recycling the pods that mount it to ensure they use the updated TLS key.

While this process is designed to be seamless, it can lead to brief disruptions. Users actively interacting with Software Hub during a pod recycling may experience temporary interruptions or, in rare cases, potential data loss if work isn't saved promptly prior to the pods recycle.

Viewing certificates through the command line can be troublesome and error prone. Extracting critical information—such as expiration dates, issuers, or subject alternative names—is often buried in verbose, unstructured output. In OpenShift environments, the challenge grows: there's no built-in, straightforward way to trace which services are using a given certificate, making troubleshooting and auditing unnecessarily difficult.

Introducing the Certificate Manager Console

To mitigate these challenges, we've developed the Certificate Manager Console. This feature provides administrators with enhanced visibility and control over the certificate renewal process without having to go to the Openshift Console or terminal:

• View Renewal times: View upcoming certificate renewal dates and plan accordingly.

• Service Association: Identify which services are utilizing a specific certificate.

• Customizable Renewal date: Optionally adjust renewal dates to better align with maintenance windows.

Conclusion

IBM Certificate Manager in IBM Software Hub 5.2 enhances the administrator's ability to manage and monitor certificates within a cluster. This version introduces a more intuitive interface for viewing certificates and their renewal timelines, enabling administrators to proactively address potential issues. To minimize operational disruptions, administrators can now schedule certificate renewals during planned maintenance windows, ensuring that renewals occur outside of peak business hours. This capability helps prevent unexpected downtime by allowing for timely updates without impacting critical services.

Demo: