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

Make it possible to ignore CN/SAN mismatches #8912

Closed
discordianfish opened this issue Nov 23, 2017 · 5 comments · Fixed by #10524
Closed

Make it possible to ignore CN/SAN mismatches #8912

discordianfish opened this issue Nov 23, 2017 · 5 comments · Fixed by #10524

Comments

@discordianfish
Copy link
Contributor

Hi,

right now deploying etcd with TLS enabled requires setting up stable names or IPs for which the certs are valid. That can be quite difficult in some environments.
On AWS for instance it's good practice to run your instances in a ASG. For things like etcd it allows controlled rolling upgrades by utilizing wait conditions etc. In general, it's the idiomatic way to group your instances. But it's not easy to get stable IPs or names for ASG instances.
This applies more or less to any dynamic environment.

It would simplify the setup of etcd and therefor the most complex part of kubernetes infrastructures a lot if etcd could be made to ignore the CN/SAN fields, e.g accept any certificate as long as it's signed by the trusted CA.

I don't even think this decreases security much in most environments, since the most likely place for an attacker to get their hands on a TLS server/peer key is on a peer itself for which the name is already valid. Either way, I think it's a reasonable trade-off.

@xiang90
Copy link
Contributor

xiang90 commented Nov 26, 2017

I am still under the impression that disabling CN/SAN checking while enabling CA checking is not easy in go TLS library. But things might be changed overtime as go adds more fields into TLS configuration.

As a first step, can you explore how to do this in go? Ideally with an example. /cc @discordianfish

@wenjiaswe
Copy link
Contributor

cc @wenjiaswe

@wenjiaswe
Copy link
Contributor

@discordianfish hello, just a friendly ping, the last update on this issue was back in January this year, I was just wondering if this issue is still relevant and need to be worked on? Otherwise, we are closing out long pending issues.

@discordianfish
Copy link
Contributor Author

AFAIK it is.

@johnyannj
Copy link

is it solved at lastest version?

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

Successfully merging a pull request may close this issue.

5 participants