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

Option to accept TLS client certificates even if they lack correct Subject Alternative Names #2056

Closed
ariddell opened this Issue Jan 7, 2015 · 8 comments

Comments

3 participants
@ariddell

ariddell commented Jan 7, 2015

I'd like to add a machine to an etcd cluster and give it a certificate signed by a ca but not worry about specifying its IP address or its domain name in the certificate. Is there or will there be a way to do this? It would make joining the cluster securely easier.

Also, to the extent that one might want to use etcd to keep track of IP addresses, there's a chicken-and-the-egg problem here.

But perhaps I'm missing some important detail here. Is there a reason why having a signed client certificate isn't sufficient? Why is SAN or DNS name required in the first place?

@ariddell ariddell changed the title from Option to accept TLS certificates even if they lack correct Subject Alternative Names to Option to accept TLS client certificates even if they lack correct Subject Alternative Names Jan 7, 2015

@sepiroth887

This comment has been minimized.

sepiroth887 commented Mar 7, 2015

Bump, im really interested in this as well, if I bootstrap an etcd cluster id like to pass everything (certs included) in the cloud-config but I only know the IP of each machine after it's started (dynamic ip allocation....)

I've considered bootstrapping a dedicated cluster but this becomes unfeasible for a large deployment i think (i'd rather have each service cluster run it's own etcd with local certs than one master ca/cert shared by all clusters)

@yichengq

This comment has been minimized.

Contributor

yichengq commented Apr 18, 2015

@ariddell This is the default requirement for go tls library, and we think it is reasonable. If you cannot provide SAN or DNS to your server certificate, it is easy to be abused or misused.

@sepiroth887 etcd member cluster should be in size of 3-9, which is acceptable for manual deployment.

@sepiroth887

This comment has been minimized.

sepiroth887 commented Jun 25, 2015

Hmmm.. it is unless you're planing to deploy say 50-90 node clusters of say 10-20 services running their own fleet. we should be able to use DNS though. That way automation is indeed possible. via IP this becomes an allocation and management nightmare.

@ariddell

This comment has been minimized.

ariddell commented Jun 25, 2015

The cloudflare PKI post from today had some comments on SAN

Internal services need to trust each other. Browsers validate website certificates by checking the signature on the certificate and checking the hostname against the list of Subject Alternative Names (SANs) in the certificate. This type of explicit check is useful, but it has a record of not working as expected. Another way for services to trust each other is an implicit check based on per-service CAs.

@sepiroth887

This comment has been minimized.

sepiroth887 commented Jun 25, 2015

Yup i wanted to go with ca based trust and avoid the need for annoying reverse dns lookups.

Scenario im thinking about here:

vm provisioning -> ip allocated -> cloud config with etcd discovery and then local etcd cluster bootstrap.

Now its easy enough to secure the discovery cluster and small enough for manual cert creation ( though anytime a machine gets a new ip the cert would need to be recreated and all machines updated.

The local cluster would also need its own secured etcd cluster to store state and some service meta data. If i want to be able to just throw more machines at the cluster to scale my services i need to rebuild a cert and reconfigure all other node accordingly. This is a major drawback making it very undesirable for large scale deployments. Imagine doing this for 1000+ VMs.

However i can easily bootstrap an etcd cluster with say a puppet master that hands out certificates either by waiting for user approval or an encrypted password injected via the cluster conf.

As long as the puppet master can identify what cluster a machine belings to it can hand out a fully ca rooted certificate to the requesting node and the cluster is secured easily and scalable.

It also means i can centralize invalidation and audit on a small cluster of puppet masters. So i still think SAN is ok but shouldnt be a requirement.

@sepiroth887

This comment has been minimized.

sepiroth887 commented Jun 25, 2015

Sorry for the typos. My hands are bleeding a bit today ;)

@ariddell

This comment has been minimized.

ariddell commented Jun 25, 2015

I was thinking of a case where one had dynamically assigned ip addresses
in some sort of overlay network -- or a case where you wanted to move
machines around without having to worry about changing the cert because
the IP address changed.

On 06/24, Tobias Haag wrote:

Yup i wanted to go with ca based trust and avoid the need for annoying reverse dns lookups.

Scenario im thinking about here:

vm provisioning -> ip allocated -> cloud config with etcd discovery and then local etcd cluster bootstrap.

Now its easy enough to secure the discovery cluster and small enough for manual cert creation ( though anytime a machine gets a new ip the cert would need to be recreated and all machines updated.

The local cluster would also need its own secured etcd cluster to store state and some service meta data. If i want to be able to just throw more machines at the cluster to scale my services i need to rebuild a cert and reconfigure all other node accordingly. This is a major drawback making it very undesirable for large scale deployments. Imagine doing this for 1000+ VMs.

However i can easily bootstrap an etcd cluster with say a puppet master that hands out certificates either by waiting for user approval or an encrypted password injected via the cluster conf.

As long as the puppet master can identify what cluster a machine belings to it can hand out a fully ca rooted certificate to the requesting node and the cluster is secured easily and scalable.

It also means i can centralize invalidation and audit on a small cluster of puppet masters. So i still think SAN is ok but shouldnt be a requirement.


Reply to this email directly or view it on GitHub:
#2056 (comment)

@ariddell

This comment has been minimized.

ariddell commented Jun 25, 2015

It looks like it really is impossible to change without forking crypto/tls (https://golang.org/pkg/crypto/tls/). What arrogance.

If I'm wrong about this, I'll reopen.

@ariddell ariddell closed this Jun 25, 2015

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