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
A note for the community
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:
Attempted Solutions
Within Vector's current features, there's no way to obtain SANs from the peer certificate:
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:
References
#11905 — the original feature that introduced tls_client_metadata (subject only)
Version
0.57.0