Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Enhanced TLS certificate metadata
See original GitHub issueThe current specification only declares a handful of TLS certificate fields. Additionally, these fields are centered around an active connection, not so much around TLS metadata. For instance tls.servername specifies that it be the servername requested by the client. If the cert is a wildcard cert, there is no place in the schema for that.
There is a certificates field, but that is somewhat under-defined. Should the certs be x.509 PEM or DER encoded? I think that description needs to be tightened up as well.
I propose that we the full list of x.509 fields to ECS, and make it clear that tls.* should be exclusively what’s in the certificate(s), not the context around the given connection.
Furthermore, I think we should remove the tls.servername field, destination.hostname should suffice for use in those situations.
Issue Analytics
- State:
- Created 5 years ago
- Comments:15 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Packetbeat has fairly extensive TLS metadata.
Not sure why, but I also feel uneasy about calculating a boolean based on an expiration date.
On the other hand I think it would be really useful to have. It’s a very important thing that’s straightforward to alert on, or display in red & so on. Everyone should catch those earlier by working off of the expiration date, but somehow there’s always that one cert somewhere, that slips through the cracks 😃
So I’m in favour 👍