Problem
When a Certificate Revocation List (CRL) is configured, ztunnel applies it only to peer certificates. It never checks whether its own workload certificate has been revoked.
If ztunnel's certificate appears in a CRL, peers will reject inbound mTLS connections—but from ztunnel's side everything looks normal. There is no log message, no warning, no hint that the local certificate is the problem. This makes the resulting connectivity failures very hard to diagnose.
There is even a TODO comment in the code acknowledging this gap:
// TODO: check if our own certificate is revoked in the CRL and log warning
Expected behavior
When a CRL is configured and ztunnel's own certificate is found in it, ztunnel should emit a warning so that operators know the certificate needs to be renewed before peers start rejecting connections.
Actual behavior
No warning is emitted. Connections silently fail on the peer side with no actionable signal on the local node.
Problem
When a Certificate Revocation List (CRL) is configured, ztunnel applies it only to peer certificates. It never checks whether its own workload certificate has been revoked.
If ztunnel's certificate appears in a CRL, peers will reject inbound mTLS connections—but from ztunnel's side everything looks normal. There is no log message, no warning, no hint that the local certificate is the problem. This makes the resulting connectivity failures very hard to diagnose.
There is even a TODO comment in the code acknowledging this gap:
Expected behavior
When a CRL is configured and ztunnel's own certificate is found in it, ztunnel should emit a warning so that operators know the certificate needs to be renewed before peers start rejecting connections.
Actual behavior
No warning is emitted. Connections silently fail on the peer side with no actionable signal on the local node.