Automatic renewal with cert-manager

If TLS certificates are automatically renewed in your API Connect deployment, you must restart the pods that are affected by the updated certificates.

1. Monitor the deployment for automatically renewed certificates.
   Tip: You can monitor the cert-manager logs manually as explained in the following steps, but you will be less likely to overlook a certificate renewal if you set up a logs-based alerting mechanism that informs you when cert-manager renews any certificate.

   • To determine when a particular certificate is due for renewal, complete the following steps:
     1. Retrieve the list of certificate names by running the following command:

        kubectl get certs

     2. From the list of certificates, choose the one you want to know about and run the following command:

        kubectl get cert certificate_name -o yaml

        The output looks like the following example:

        apiVersion: cert-manager.io/v1alpha1
        kind: Certificate
        metadata:
          ...
        spec:
          commonName: management-server
          ...
          duration: 12720h0m0s
          ...
          renewBefore: 24h0m0s
          secretName: management-server
        status:
          ...
          notAfter: "2022-06-21T16:28:47Z"
          ...

        In the example, you can see that the certificate will expire by 2022-06-21T16:28:47Z (status.notAfter) and the renewal will take place 24 hours (spec.renewBefore) before that time. This can be used to keep track of which certificates will be renewing when to perhaps to have a better idea of when to lookout for renewals for each cert in the cert-manager logs.

   • To determine when a certificate was renewed, complete the following steps:
     1. Run the following command to display the cert-manager log:

        kubectl logs Cert-manager_pod_name -n cert-manager

     2. In the log output, look for lines similar to the following example:

        I0108 14:23:18.001074       1 controller.go:129] cert-manager/controller/certificates "level"=0 "msg"="syncing item" "key"="default/test-cert" 
        I0108 14:23:18.009940       1 issue.go:109] cert-manager/controller/certificates/certificates/issue "level"=0 "msg"="certificate issued" "related_resource_kind"="Secret" "related_resource_name"="test-cert" "related_resource_namespace"="default" 
        I0108 14:23:18.018664       1 sync.go:331] cert-manager/controller/certificates/certificates "level"=0 "msg"="certificate scheduled for renewal" "duration_until_renewal"="-5.018566857s" "related_resource_kind"="Secret" "related_resource_name"="test-cert" "related_resource_namespace"="default" 
        I0108 14:23:18.019070       1 controller.go:135] cert-manager/controller/certificates "level"=0 "msg"="finished processing work item" "key"="default/test-cert" 

        The 4 statements (shown in the example) indicate when a certificate is about to be renewed, and when the renewal is complete a few seconds later.

2. If a CA certificate was renewed, renew all of the certificates issued by that CA's issuer.

   For the list of CA certificates and issuer, see List of Issuers, CA certificates, and secrets.

3. Restart pods affected by the renewed certificates.

   When the logs show that a certificate was renewed, restart the pods that use the secret based on that certificate, so that the pods can load the renewed secret.

   1. Determine which pods are affected by the updated certificate by reviewing the following topics:
      • List of external certificates
      • List of internal certificates
   2. Restart the pods affected by the certificate as explained in the following topics:
      • Management subsystem: restarting pods
      • Gateway subsystem: restarting pods
      • Analytics subsystem: restarting endpoints and pods
      • Portal subsystem: restarting pods for a two data center configuration or Cloud Pak for Integration

        If you are using a single data center configuration with a stand-alone API Connect deployment, the Portal subsystem pods pick up the new certificates and restart any internal processes automatically. Changing the portal-server or portal-client certificates will be a zero downtime operation. However, changing the portal-ca certificate will cause downtime because all portal-db pods need to restart MySQL to allow for the certificate to update. The pods will not restart, but they will all go non-ready and then ready again, which will take a few minutes.