cert-manager renews certificates automatically before they expire, so a working setup needs no calendar reminders. This page covers how renewal happens, how to monitor it, and how to force or recover one when necessary.

## Automatic renewal

Each `Certificate` has a `renewBefore` window. cert-manager renews once the certificate reaches that proximity to expiry, well ahead of the deadline. For a 90-day Let's Encrypt certificate, the default renews it approximately one third of the way before expiry, leaving ample time to retry if a renewal fails. You can shorten the window per `Certificate`:

```yaml
spec:
  renewBefore: 720h # renew 30 days before expiry
```

When cert-manager renews, it writes the new certificate into the same Secret. An ingress controller watching that Secret loads the new certificate and serves it, with no restart and no dropped connections.

```mermaid
flowchart LR
    A[Certificate issued] --> B[cert-manager watches expiry]
    B --> C{Inside renewBefore<br/>window?}
    C -- no --> B
    C -- yes --> D[Request a fresh cert over ACME]
    D --> E{Challenge passed?}
    E -- no --> H[Back off, retry later]
    H --> D
    E -- yes --> F[Write new cert to the same Secret]
    F --> G[Ingress reloads the Secret,<br/>serves the new cert]
```

## Watch a certificate

```console
$ kubectl get certificate
NAME                  READY   SECRET                 AGE
app-example-com-tls   True    app-example-com-tls    60d
$ kubectl describe certificate app-example-com-tls
```

The events on the `Certificate` show the last renewal and any failure. `READY: True` with a recent renewal event is a healthy certificate.

## Force a renewal

To rotate ahead of schedule, for example after a suspected key exposure, trigger a renewal with the cert-manager CLI:

```console
$ cmctl renew app-example-com-tls
```

cert-manager requests a fresh certificate and updates the Secret. Do not rotate in a tight loop; each renewal is an actual request against the certificate authority.

## Alert before expiry

Automatic renewal usually just works, but a broken solver (a DNS record removed, an ingress that stopped answering the challenge) can let a certificate drift toward expiry unnoticed. Alert on the certificate's remaining lifetime so a stuck renewal surfaces before it becomes an outage. cert-manager exposes each certificate's expiry as a metric; wire it into your monitoring, and see [Platform alert rules](/docs/hetzner/apalla/observability/alerting/platform-alert-rules#certificate-expiry) for the certificate-expiry rules and the node-level certificates the health daemon reports on.

> [!NOTE]
> A failed renewal backs off and retries; it does not overload the certificate authority. If renewals keep failing, fix the underlying solver (DNS-01 record, HTTP-01 reachability) rather than forcing renewals, or you will exhaust the domain's rate limit on attempts that cannot succeed.

<Collapsible title="CA and intermediate rotation">

When a certificate authority rotates its intermediate, cert-manager adopts the new chain on the next renewal, so your certificates continue validating without action. If you run your own CA `Issuer`, rotating that CA's key means every certificate it signed must be re-issued: plan the rotation so the old and new CA are both trusted during the overlap, then renew the leaf certificates.

</Collapsible>

## Where to go next

- [Set up a Let's Encrypt ClusterIssuer](/docs/hetzner/apalla/network/dns-certs/lets-encrypt-clusterissuer)
- [Install cert-manager](/docs/hetzner/apalla/network/dns-certs/install-cert-manager)
- [Platform alert rules](/docs/hetzner/apalla/observability/alerting/platform-alert-rules)