Add experimental certificate search to the KMS layer

[dopey]

Adds an experimental CertificateSearcher KMS interface and its CAPI (Windows) implementation: enumerate a certificate store and return each certificate together with its CNG key-container name, read from the CERT_KEY_PROV_INFO property rather than by opening the key — so certificates whose private key no longer exists are still reported and can be identified for cleanup.

Motivation: a Windows certificate store can accumulate certificates whose backing key is gone. Such a certificate still reports HasPrivateKey=True (the property survives key deletion), still looks healthy in certlm.msc, and can still be selected by schannel for EAP-TLS — failing only at handshake time. Identifying these requires reading the key-container association from certificate properties without opening the key, which no current KMS API exposes.

Alternative considered: extending CleanupCredentials with a non-expired mode. Rejected because deciding which unexpired certificates to remove is caller policy — expressing it would mean the API absorbing caller naming schemes or accepting pattern arguments — and because CleanupCredentials is safe by construction today (expired-only means it cannot destroy a working credential), a property worth keeping. Search + the existing DeleteCertificate keeps the read side harmless and the destructive operation precise. A composite cleanup could still be layered on this primitive later.

What's in here

• kms/apiv1: CertificateSearcher (embeds KeyManager, matching the SearchableKeyManager precedent rather than the bare-interface CredentialsCleaner style) + request/response types, all marked Experimental
• kms/capi: SearchCertificates implementation; a fix for cryptFindCertificateKeyContainerName, which previously passed a nil buffer on its second property call and unconditionally returned an empty name (it had no callers, so nothing depended on the broken result)
• kms/capi: certContextToX509 now clones the DER before parsing. x509.ParseCertificate aliases its input, so the helper previously handed out certificates whose Raw/RawSubject/etc. pointed into store-owned memory — freed on the next enumeration advance, or kept alive only by unclosed store handles. This is a strict correctness improvement for the pre-existing callers (LoadCertificate, FindCertificatesByIssuer, CleanupCredentials) as well.
• kms/capi: runtime.KeepAlive in the container-name reader — the name is an interior pointer into a []byte the GC scans as pointer-free, so the buffer must be pinned across the UTF-16 walk
• kms/platform: pass-through following the CleanupCredentials pattern, with per-OS tests

Design decisions worth calling out

• SearchCertificates closes its store handle; the file's five other CertOpenStore sites do not (pre-existing, deliberately untouched). A search API invites frequent calls from long-running processes, where an unclosed handle per call accumulates without bound; changing the other sites' behavior was out of scope here.
• Partial results on error: a mid-enumeration failure returns the certificates gathered so far alongside the error, documented on the interface and the wrapper (same contract discussion SearchKeys went through).
• Per-certificate failures skip (unparseable DER, unreadable properties) rather than failing the search — best-effort metadata by contract.

Verification

CI here runs ubuntu-only, so none of the windows-tagged code executes in CI — stating exactly what was run locally:

• go build ./..., go test ./kms/... (host; the new per-OS NotImplementedError tests run here)
• GOOS=windows GOARCH=amd64 go build ./kms/... and go vet — clean; the one vet finding (ncrypt_windows.go possible misuse of unsafe.Pointer) is pre-existing at the merge base in an untouched function
• GOOS=windows GOARCH=amd64 golangci-lint run ./kms/capi/... ./kms/platform/... — zero new findings vs the merge base
• Windows-tagged tests (kms/capi/capi_windows_test.go, the new delegation test in kms/platform/kms_windows_test.go) compile under GOOS=windows and run on Windows machines; the delegation test asserts the searched certificate's recorded container name against the stored value, so it distinguishes the fixed property-reader from the stub it replaced

🤖 Generated with Claude Code

[dopey]

Validation beyond what CI can exercise: the full production path — platform KMS constructed from a default kms: URI (TPMKMS backend) → capi → LocalMachine\My — was run end-to-end on TPM-equipped Windows VMs. Both target scenarios pass: superseded-certificate cleanup on re-issuance, and the orphaned case — a deployed certificate whose CNG key no longer exists, found by container name via the property read and deleted by thumbprint. The TPMKMS.SearchCertificates commit exists because that end-to-end run caught the default-URI routing going to the TPM backend, which the original capi-only implementation never received; the host-runnable delegation tests added alongside pin that seam in ubuntu CI permanently.

[maraino]

The change looks good, but I think is too CAPI-specific, I've suggested a change that might make it more generic.

[maraino]

I believe this is the key name, right? At least in capi, the keyContainerName in the URI comes from the key parameter.

If this is the case, why don't we make this more generic and rename it to KeyName?

[darkfronza]

two minor comments

[darkfronza]

Perhaps we should errors.Join this error with any relevant information from certHandle, silently ignoring it will make debugging harder.

[darkfronza]

Perhaps we should errors.Join this error with any relevant information from certHandle, silently ignoring it will make debugging harder.