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

[ariddell]

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?

[sepiroth887]

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]

@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]

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]

The cloudflare PKI post from today had some comments on SAN

• https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/

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]

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]

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

[ariddell]

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]

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.