You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add in TLS parser client certificate capture in mTLS + make it searchable #4151
It is a feature request. Due to a scenario where all TLS captured traffice need to be scrutinized, client certificates identification, index and create a way to search them are desirable options to optimize troubleshootings.
changed the title [-]Add in TLS parser client certificate capture in mTLS[/-][+]Add in TLS parser client certificate capture in mTLS + make it searchable[/+]on Jul 23, 2026
Hi Awick! I think reuse the current cert fields may be less complex than creating a new object and a set of fields only for that purpose. But it is important to mention that in the same connection both certificates must be captured and available to be searchable in the platform. Then, the flag is crucial to filter which certificate (or bundle) is from the client and which one (or bundle) belongs to the server.
unfortunately you wouldn't be able to say "cert.client == true && cert.somefield == something" and have it only return sessions where there is a client cert with somefield is something. Instead it would return sessions where there is ANY client cert AND it has ANY cert where somefield is something. They don't have to be the same cert. This is how dns/http/etc all work. If they must be the same cert for the query then we need new fields.
Of course the display would show the cert is the client one.
In that case, it would be desirable to have different fields for client certificate in order to allow queries with distinct client cert specific attributes. For example, identify cert clients about to expire.
Activity
[-]Add in TLS parser client certificate capture in mTLS[/-][+]Add in TLS parser client certificate capture in mTLS + make it searchable[/+]awick commentedon Jul 29, 2026
Do you think this should be a new set of fields ore reuse the current cert fields, maybe with a new flag of client vs server?
ricardomvalverde commentedon Jul 29, 2026
Hi Awick! I think reuse the current cert fields may be less complex than creating a new object and a set of fields only for that purpose. But it is important to mention that in the same connection both certificates must be captured and available to be searchable in the platform. Then, the flag is crucial to filter which certificate (or bundle) is from the client and which one (or bundle) belongs to the server.
awick commentedon Jul 29, 2026
unfortunately you wouldn't be able to say "cert.client == true && cert.somefield == something" and have it only return sessions where there is a client cert with somefield is something. Instead it would return sessions where there is ANY client cert AND it has ANY cert where somefield is something. They don't have to be the same cert. This is how dns/http/etc all work. If they must be the same cert for the query then we need new fields.
Of course the display would show the cert is the client one.
ricardomvalverde commentedon Jul 29, 2026
In that case, it would be desirable to have different fields for client certificate in order to allow queries with distinct client cert specific attributes. For example, identify cert clients about to expire.