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

subjectAltName verification #48

Closed
mrichar1 opened this issue Feb 26, 2020 · 5 comments
Closed

subjectAltName verification #48

mrichar1 opened this issue Feb 26, 2020 · 5 comments

Comments

@mrichar1
Copy link

Would it be possible to add server SAN verification to the tls config in this exporter? This would allow us to use our existing certificate setup without having to take extra steps to do verification.

I'm not a go programmer, but after a brief look at the code I think the methods outlined in this blog post would do the job:

https://dev.to/living_syn/validating-client-certificate-sans-in-go-i5p

I'm happy to try and create a PR if that would be useful?

@tcolgate
Copy link
Collaborator

I'll take a look. It's a reasonable feature, and I'm not opposed. I can't promise I'll get to it in the next week though. I'd, of course, encourage you to give it a try and raise a PR. You get the added glory of your name in the AUTHORS file.

@tcolgate
Copy link
Collaborator

I should have checked what you actually want here. I /think/ you want to be able to limit verification based on the SAN presented in the clients cert? (the example you linked to is just enabling a check that checks the cert usage I think)

@mrichar1
Copy link
Author

Hi - yes we were envisaging using the SAN in the client cert to allow/prevent access (i.e checking one presented by the prometheus server when it pulls data from the exporter).

@tcolgate
Copy link
Collaborator

tcolgate commented May 1, 2020

So a regex match on the client cert's SAN would work? (this has been suggested before and is what I assumed you wanted, just want to clarify)

@mrichar1
Copy link
Author

mrichar1 commented May 1, 2020

That would be perfect, yes!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants