Key features and benefits of CertificateManager

The CertificateManager focuses on automating certificate regeneration, improving the management of ownership and expiry tracking to ensure smooth and uninterrupted operation.

Certificate renewal

Active expiry monitoring

The system monitors the expiry dates of both TLS and CA certificates every 7 days.

TLS certificate renewal

TLS certificates have a validity of 1 year.

For Operator owned certificates, the system triggers regeneration 30 days before the expiry date to ensure timely renewal.
For user owned certificates, Operator raises an event before 30 days of expiry and you can subscribe to that event to get a hook and then set the following annotation in the certificate manager instance to regenerate the certificate.
```
apps.oms.gateway.ibm.com/regenerate-tls-cert: 'true'
```

CA certificate renewal

CA certificates have a validity of 10 years. Certificate is regenerated 1 year before expiration, to avoid service disruptions.

Automatic renewal

The entire renewal process is automated, eliminating the need for manual intervention and ensuring that certificates are regenerated well in advance. By renewing certificates before they expire, the system ensures that there is no risk of expired certificates affecting service functionality.

Certificates regeneration with zero downtime

CA certificates regeneration

Coexistence of old and new CA certificates: During the transition period, both the old and new CA certificates exist together for one year that is from the 9th to the 10th year.
The old CA certificate remains valid until its expiration in the 10th year. During this overlapping period, both certificates are available for validation, allowing services to authenticate certificates by using either the old or the new CA. This overlap ensures that there are no disruptions to services during the regeneration process.
The new sip-operator-ca secret includes only the following components:
- tls.crt: It contains both the old and new certificates.
- tls.key: It contains only the latest private key.
- In the case of a CA, only tls.crt and tls.key are present.
After the 9th year, the new CA certificate is used for creating or regenerating TLS certificates.
After the 10th year, after the old CA certificate expires, it is deleted, and only the new CA certificate remains in use.

TLS certificate regeneration

For Operator owned TLS certificates, TLS certificates are regenerated 30 days before expiration. The services continue to use the new TLS certificates seamlessly, as the old certificates remain valid until their expiration date. This ensures continuous service operation without any interruption during the TLS certificate renewal.
The TLS secret includes the following components:
- tls.crt: It contains the latest certificate.
- tls.key: It contains only the latest private key.
- tls.p12: It contains the latest certificate in PKCS12 format.
- tls.p12.password: It contains the password for the PKCS12 file and this password is fixed.
When an Operator owned certificate is regenerated such as sip-cert, all the respective pods that rely on that TLS secret are restarted.
For Operator owned certificates, Operator regenerate the certificate 30 days in advance to ensure a smooth transition. If a certificate is regenerated but the corresponding pod is not restarted, it might continue to use the old certificate. By allowing a 30-day buffer, Operator provides sufficient time for the pod to restart and avoid scenarios where calls to the pod fail due to an expired certificate.

Seamless transition for zero downtime

If the TLS certificate secret of sip-operator-ca certificate is deleted, a new certificate is created automatically and the corresponding pods initiate a restart. If the TLS certificate secret or sip-operator-ca certificate secret is deleted, a respective new certificate is created automatically and the corresponding pods initiate a restart.
If you create the certificate manager instance, you are notified through an event that current certificate is not using the current sip-operator-ca and it can be regenerated through the following annotation in certificateManager instance.
```
apps.oms.gateway.ibm.com/regenerate-tls-cert: 'true'
```

Centralized CA secret

Shared CA for all certificates: A centralised sip-operator-ca secret is used to sign all TLS certificates for different Certificate Manager instances. This centralization simplifies certificate management and reduces the need for individual CA management for each instance.

Status tracking

Certificate status updates

The Certificate Manager tracks and updates the status of certificates every 7 days, reflecting when they are renewed and their new validity period. This helps administrators keep track of the health and validity of the certificates at any time.

Status of the certificate manager instance

The following snippet shows the status where it indicates the secret name that contains the certificate and the certificate authority name using which it is created.

status:
    certificateAuthorityName: sip-operator-ca
    condition:
      lastTransitionTime: '2025-01-07T04:45:18Z'
      message: Certificate created
      reason: ExecutionCompleted
      status: 'True'
      type: CertificateCreated
    expirationTimestamp: '2026-01-07T04:44:31Z'
    creationTimestamp: '2025-01-07T04:44:31Z'
    renewalTimestamp: '2025-12-08T04:44:31Z'
    secretName: sip-cert

Annotations in sip-operator-ca secret

To ensure easy tracking, the expiry status of the CA certificate, sip-operator-ca is stored as annotations.
These annotations include the following two key pieces of information.
- current-certificate-status: This annotation contains the most recent information of the certificate, including the current expiration date, renewal time, and other important details.
- old-certificate-status: This annotation preserves the status of the previously used certificate, ensuring historical data is retained for auditing and troubleshooting purposes. This annotation is removed once the old certificate is removed from the secret.

Following snippet shows a sample sip-operator-ca status object.

current-certificate-status: "{"status": { "expirationTimestamp": "2035-01-07T04:44:31Z", "creationTimestamp":"2025-01-07T04:44:31Z", "renewalTimestamp": "2034-01-07T04:44:31Z"}}"
old-certificate-status: "{"status": { "expirationTimestamp": "2035-01-07T04:44:31Z", "creationTimestamp":"2025-01-07T04:44:31Z", "renewalTimestamp": "2034-01-07T04:44:31Z"}}"