-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Comments
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 |
cc @wenjiaswe |
@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. |
AFAIK it is. |
is it solved at lastest version? |
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.
The text was updated successfully, but these errors were encountered: