Certificate revocation list (CRL) enforcement

Enforce a Certificate Revocation List (CRL) on ztunnel outbound connections to reject peers with revoked certificates.

Use Certificate Revocation Lists (CRL) to revoke workload certificates in the ambient mesh. When enabled, ztunnel checks the CRL on every new inbound and outbound connection and rejects connections from peers with revoked certificates.

Before you begin

Configure a plugged-in CA for istiod by using the credentials in the cacerts secret in the istio-system namespace. For example, you can use OpenSSL, Vault, AWS Private CA, or other tools to provide the CA certificate and key. CRL enforcement requires the CA to be plugged in through istiod’s cacerts secret. The default Istio self-signed CA does not support CRL distribution.

Enable CRL enforcement

1. Generate a CRL from your CA in PEM format. The steps to generate a CRL depend on your CA implementation.

2. Add the CRL to your existing cacerts secret in the istio-system namespace as a ca-crl.pem entry.

   kubectl patch secret cacerts -n istio-system \
     --type merge \
     -p "{\"data\":{\"ca-crl.pem\":\"$(cat ca-crl.pem | base64 | tr -d '\n')\"}}"

3. Enable CRL propagation in istiod. Istiod reads the ca-crl.pem entry from the cacerts secret and propagates it as a ConfigMap to every namespace in the mesh.

   helm upgrade istiod oci://us-docker.pkg.dev/soloio-img/istio-helm/istiod \
     --version 1.30.3-solo \
     --namespace istio-system \
     --reuse-values \
     --set pilot.env.PILOT_ENABLE_CA_CRL=true

4. Enable CRL enforcement in the ztunnel. Ztunnel mounts the ConfigMap that istiod created as a volume and loads the CRL. New inbound and outbound connections from ztunnel to peers with revoked certificates are rejected.

   helm upgrade ztunnel oci://us-docker.pkg.dev/soloio-img/istio-helm/ztunnel \
     --version 1.30.3-solo \
     --namespace istio-system \
     --reuse-values \
     --set peerCaCrl.enabled=true

5. Multicluster only: If your mesh includes an east-west gateway, enable CRL enforcement on the peering chart as well. Without this, connections that traverse the east-west gateway do not enforce the CRL.

   helm upgrade peering-eastwest oci://us-docker.pkg.dev/soloio-img/istio-helm/peering \
     --version 1.30.3-solo \
     --namespace istio-eastwest \
     --reuse-values \
     --set eastwest.peerCaCrl.enabled=true

Update the CRL

To update the CRL, patch the cacerts secret with the new PEM file. No ztunnel restart is required.

kubectl patch secret cacerts -n istio-system \
  --type merge \
  -p "{\"data\":{\"ca-crl.pem\":\"$(cat ca-crl-updated.pem | base64 | tr -d '\n')\"}}"

Istiod detects the change and updates the ConfigMap in each namespace. Ztunnel reloads the updated CRL automatically within the kubelet’s volume sync interval, typically 60–90 seconds.

Considerations

• New connections only: CRL enforcement applies to all new connections, both inbound and outbound. Existing connections are not affected when a CRL update is loaded. Established connections remain active until ztunnel restarts and re-establishes them against the updated CRL.
• CRL update propagation delay: CRL updates propagate to ztunnel within the kubelet’s volume sync interval, typically 60–90 seconds. During this window, ztunnel continues to enforce the previous CRL.
• Plugged-in CA required: CRL enforcement requires a custom intermediate CA configured via the cacerts secret. The default Istio self-signed CA does not generate or distribute CRLs.
• Solo distribution of Istio: CRL enforcement via the peerCaCrl Helm value is available in the Solo distribution of Istio. The underlying ztunnel CRL enforcement code was contributed upstream to the Istio open source project.