Support client certificate authentication (mTLS) for registry access #1344

Is your feature request related to a problem?

In environments where OCI registries are secured using mutual TLS (mTLS), Notation CLI notation verify cannot authenticate to the registry.

While container runtimes (e.g. containerd) can successfully pull images using mTLS, Notation fails during registry interaction (e.g. GET /v2/) because it does not present a client certificate. This typically results in TLS handshake failures or HTTP 400/403 responses from reverse proxies or ingress controllers.

As a result, Notation cannot:

• resolve image manifests
• retrieve OCI referrers (signatures)
• perform signature verification

This creates a gap where image pulls succeed but signature verification cannot be enforced.

What solution do you propose?

Add support for client certificate authentication (mTLS) when interacting with registries.

For example, via CLI flags:

notation verify <image> \
  --cert client.crt \
  --key client.key \
  --cacert ca.crt

Alternatively (or additionally), support:

• configuration-based TLS settings (per registry)
• reuse of existing container runtime configuration (e.g. /etc/containerd/certs.d)
• integration with underlying ORAS transport configuration

This would allow Notation to authenticate to mTLS-protected registries and complete verification workflows.

What alternatives have you considered?

• Introducing a reverse proxy to terminate mTLS and expose a non-mTLS endpoint for Notation
  → adds architectural complexity and weakens end-to-end security guarantees
• Using different registry authentication mechanisms (basic auth, tokens)
  → not always possible in environments where mTLS is mandated
• Running verification through custom services or wrappers that handle mTLS
  → increases operational overhead and complexity
• Relying on Kubernetes admission controllers (e.g. Kyverno)
  → these still require registry access and face the same limitation

None of these provide a clean or native solution.

Any additional context?

This issue is particularly relevant in Kubernetes environments where:

• container runtimes (e.g. containerd) are configured with mTLS for image pulls
• Notation is used for supply chain security and signature verification
• admission policies aim to enforce signed images

In these setups, there is currently a mismatch:

• image pulls succeed (mTLS supported by runtime)
• signature verification fails (mTLS not supported by Notation)

Supporting mTLS in Notation would improve compatibility with secure, enterprise-grade registry deployments and enable consistent enforcement of image signing policies.