Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add chain depth limit to x509 input #4927

Closed
dimas opened this issue Oct 26, 2018 · 10 comments
Closed

Add chain depth limit to x509 input #4927

dimas opened this issue Oct 26, 2018 · 10 comments
Labels
feature request Requests for new plugin and for new features to existing plugins

Comments

@dimas
Copy link

dimas commented Oct 26, 2018

Discovered the new x509 plugin and tried playing with it a bit.
Seems to be very useful for our purpose but there are couple of things that ask for improvement.

First, makes sense to give user ability to limit the depth of the cert chain. Right now metrics are generated for the server certificate itself as well as for all chain cert if server reports them. In reality most of the time you are only interested in the “leaf” server certificate not all its issuers. So either a numeric max_depth or a boolean include_chain option would be nice.

Second is the ability to specify server name. From the code it looks like TLSConfig servername gets overwritten by what you configured as a source (u.Host). Often you are going to put localhost as the source because telegraf runs on the server. But at the same time you would like to verify the name in the cert. Right now you cannot and the only option is to disable security completely. (or hack /etc/hosts)
This one is not a huge problem and I am not sure you will ever want fixing so not raising as a separate issue.

@glinton glinton added the feature request Requests for new plugin and for new features to existing plugins label Oct 26, 2018
@loganmarchione
Copy link

I would also be interested in this. Looking to monitor specific "leaf" certs, not the entire chain.

@x70b1
Copy link
Contributor

x70b1 commented Aug 4, 2022

As this is still unresolved, I would like to make a comment on this.

The use case for this plugin is probably in 99%: Which certificates do I have and how long are they still valid?

The problem I see at the moment is: Because the whole chain is stored, it is not possible to get a query result with a single paremeter. The source tag returns multiple certificates. It still needs common_name to filter out the "leaf".

I would like to have a simple solution that gives me the answer of the expiration date with only one parameter, for example source.

@loganmarchione
Copy link

Does this PR fix this issue?

#9822

@x70b1
Copy link
Contributor

x70b1 commented Nov 16, 2022

@loganmarchione

I have not tested it, But it looks very like this. Yeah!

@srebhan
Copy link
Member

srebhan commented Nov 16, 2022

@loganmarchione and @x70b1 are you only interested in leaf vs complete depth or would you also be interested in validating until a depth of 2 or so?

@loganmarchione
Copy link

@srebhan I was only interested in leaf vs complete depth. In my example, I run PKI at home, so I have:

root cert
 |
 |
 ----> intermediate cert
        |
        |
        ----> host cert

@srebhan
Copy link
Member

srebhan commented Nov 16, 2022

@loganmarchione in this case exclude_root_certs = true is what you want. The naming is a bit misleading though.

@x70b1
Copy link
Contributor

x70b1 commented Nov 16, 2022

Thats enough I would say.
Would it be an idea to make true the default for exclude_root_certs?

@srebhan
Copy link
Member

srebhan commented Nov 16, 2022

@x70b1 as we are committed to keep the behavior stable for existing configs we cannot make this change as it would change behavior for everyone wanting the whole chain and did not explicitly set it...

Will close this issue as it seems like we have a working solution. If you disagree, please feel free to reopen the issue.

@srebhan srebhan closed this as completed Nov 16, 2022
@x70b1
Copy link
Contributor

x70b1 commented Nov 16, 2022

Will close this issue as it seems like we have a working solution. If you disagree, please feel free to reopen the issue.

I am fine with this. Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests for new plugin and for new features to existing plugins
Projects
None yet
Development

No branches or pull requests

5 participants