warn when own certificate appears in a configured CRL

[jlojosnegros]

When CRL checking is enabled, ztunnel validates peer certificates against the configured CRLs but never checks whether its own workload certificate appears in any of those lists. If the local certificate is revoked, peers will start rejecting inbound HBONE connections without ztunnel having any indication of why.

This adds a self-revocation check inside WorkloadCertificate::build_tls_config:
after fetching the CRL DERs from the manager, find_cert_revocation scans each
CRL for the workload certificate's serial number. If a match is found, a warn!
log is emitted with the certificate serial, SPIFFE identity, and revocation
reason (when present in the CRL entry). The check is purely diagnostic — the
TLS config is still built normally so ztunnel continues to operate fail-open,
consistent with the existing allow_unknown_revocation_status policy.

find_cert_revocation is intentionally kept narrow: it only compares serial
numbers within CRLs that can be successfully parsed; malformed CRL entries
are logged at debug level and skipped.

A unit test covers both the positive case (own serial listed in CRL returns
Some) and the negative case (unrelated serial returns None).

Closes #1767

[istio-testing]

Hi @jlojosnegros. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jlojosnegros]

Hi all 👋 - new contributor here.

@nilekhc you added the TODO this PR resolves (in #1660). Would you mind taking a look when you have a moment?

@howardjohn @keithmattix @ilrudie - pinging you as recent contributors to the file in case you have bandwidth for a quick review.

Also, would someone be able to run /ok-to-test so CI can run?

Happy to address any feedback!

[ilrudie]

/ok-to-test

[jlojosnegros]

Thanks for the label @ilrudie :)