tls_client_metadata should expose Subject Alternative Names (SANs) from the client certificate

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

Vector sources that accept TLS connections can capture metadata about the client certificate when tls.client_metadata_key is set. Today that metadata contains only the certificate subject (the distinguished name, e.g. CN=...,OU=...,O=...).

Modern PKI no longer relies on the subject to identify an entity. Since the CA/Browser Forum began enforcing it in 2018, certificate identity is expressed in the Subject Alternative Name (SAN) extension (RFC 5280 §4.2.1.6) — DNS names, IP addresses, email addresses, and URIs. Client certificates issued for mTLS typically carry the service/host identity (e.g. DNS:app-1.internal, IP Address:10.0.0.7) in the SANs, while the subject only holds generic organization details.

Concretely, operators want to:

• Distinguish clients in mutual-TLS deployments
• Enrich, route, and filter on client identity — e.g. attach ownership tags based on DNS: SAN, or send traffic from specific client IPs/names to different sinks.
• Audit and comply — record exactly which certificate identity was presented, matching the output operators already see from openssl x509 -text.

Attempted Solutions

Within Vector's current features, there's no way to obtain SANs from the peer certificate:

• The subject field doesn't contain SANs, and parsing the DN can't recover them — a cert with SANs isn't required to duplicate them in the subject.
• Parsing the certificate outside Vector (e.g. in a proxy or external enrichment service) means duplicating the handshake/cert-extraction logic and keeping a second source of truth.

Proposal

Extend the tls_client_metadata object emitted by all sources that support client_metadata_key (fluent, logstash, socket, statsd, syslog, and the TCP-mode dnstap source) with a subject_altnames field:

• A comma-separated list of SANs, each prefixed with its type to match openssl x509 -text (e.g. DNS:localhost,IP Address:127.0.0.1).
• Requires no config change — it's additive to the existing client_metadata_key output.

References

#11905 — the original feature that introduced tls_client_metadata (subject only)

Version

0.57.0

Start by locating the shared tls_client_metadata emission path and its integrations in the fluent, logstash, socket, statsd, syslog, and TCP-mode dnstap sources. Trace how client certificates are extracted, then verify that each listed source exposes subject_altnames with typed, comma-separated SAN values alongside the existing subject metadata.