rebuild-ca and regenerate-certs commands

[ehazlett]

This adds tls-rebuild-ca and tls-regenerate-certs for rebuilding the local CA cert and keys as well as generating new certificates and propagating them to the specified machines. This should resolve issues like #531 as well as provide a mechanism to completely re-key all machines.

[emil-palm]

+1

[sthulb]

Perhaps this can be linked into my PR about certs/identity #688

[ehazlett]

@sthulb +1. Right now, there isn't much to it. It simply calls the other functions to regenerate. I think your PR is needed for machine server. This would temporarily give rotation capabilities and the ability to reset the TLS config on the engine (assuming you have the SSH keys).

[sthulb]

Sure, implement them how you want for now, whilst we're < 1.0 we can fiddle with command structure.

[ehazlett]

@bfirsh thoughts? i went back and forth on the naming. i'm not tied to them.

[jmorganca]

👍

[bfirsh]

A command for this would help people get out of that crappy situation, I suppose. Though I'm a bit concerned about adding this because we're not fixing the root cause of a bug.

Questions:

• Are there any reasons why you want to rotate all of your keys, beyond fixing that bug and general good security practice?
• Why would you want to rebuild your CA?
• I wonder if we need both commands... If you rebuild your CA, don't you always need to regenerate your certs? If you want to rebuild all your certs, is there any harm in also rebuilding the CA?

[ehazlett]

Unfortunately, I cannot get this reproduced. What appears to be happening is the IP SAN isn't valid for the specified cert (even though changing IPs I cannot reproduce). I don't think there is any other way to fix this unless we set a wildcard for all access. Perhaps this would be ok for the local drivers but I think the potential would still be there for the cloud providers too. Take ec2 for example, you could stop and get another IP. I don't know any other way than regenerating certificates.

General good security practice for start. If your CA gets compromised, you would want to build a new one. If you generate a new CA, you don't have to regenerate all certs because we store a copy of the ca and cert in the machine directory to be self-contained. This allows for a "rolling" cert re-issue.

[bfirsh]

I think setting a wildcard hostname and verifying the exact cert is a good idea. I'm pretty sure if you don't need a CA for Docker's TLS. You can pass the host's certificate to --tlscacert directly and it'll verify that the host is presenting exactly that certificate.

[bfirsh]

In terms of naming, I like commands which start with verbs. So if we're having one command, I would vote regenerate-certs. If we're having two commands, it's a bit more complex...

[ehazlett]

Ok so for server certs we generate a wildcard? I think it's less secure but would alleviate the issue and as long as we verify the cert I would be ok with it.

thoughts @sthulb @ggiamarchi @andrewwatson

[ehazlett]

i don't think we would want to force a regeneration of the CA as that would cause confusion I think. I think two commands is better.

[bfirsh]

Why would you want to regenerate the CA? If that's something that doesn't happen that often, could we recommend running rm -r ~/.docker/machine/certs; docker-machine regenerate-certs?

[ehazlett]

I think this could be modified to only generate the CA certs if they don't exist and thus a single command would suffice.

[md5]

FYI, I don't think you can "wildcard" with an IP SAN, so you'd have to create a fake hostname/domain name for the Machine-created Docker hosts.

[md5]

I think setting a wildcard hostname and verifying the exact cert is a good idea. I'm pretty sure if you don't need a CA for Docker's TLS. You can pass the host's certificate to --tlscacert directly and it'll verify that the host is presenting exactly that certificate.

@bfirsh Could you clarify what you mean here?

[md5]

Will Go not check that the certificate used as a trust root includes the CA extension?

[md5]

I'm pretty sure it checks for the CA extension of the asserted trust roots here: https://github.com/golang/go/blob/c2317db2f9bf9f097f0bc297004a8f581b944206/src/crypto/x509/x509.go#L593 (which is called from here https://github.com/golang/go/blob/439b32936367c3efd0dadab48dd51202e1a510f1/src/crypto/x509/cert_pool.go#L31)

[sthulb]

I'm ok with wildcard certs if we can generate them.

[ehazlett]

it looks like @md5 is correct. I just tried to create some using wildcards (* and 0.0.0.0) which both do not work. It looks like we are going to have to support either detection of failed connections or the ability to re-cert as we probably cannot rely or generate hostnames for all instances.

[ehazlett]

@bfirsh so we ran into this again in irc. i think this would be good to get in. I think removing the CA command and defaulting to relying on removing manually would suffice for now. thoughts?

[bfirsh]

@ehazlett 👍 that sounds great. I think a single regenerate-certs command would be easier to understand.

Actually, come to think of it, isn't the CA generated automatically on first start if it doesn't exist?

[ehazlett]

@bfirsh correct -- if the ca/client certs do not exist, they get auto-generated on first machine create.

[ehazlett]

Closing this PR in favor of #770. It is the exact same (which the name as regenerate-certs) only created against the new driver refactor for easier merge.

[sporkmonger]

FWIW, I just ran into this after running b2d via Kitematic and then spinning up two other docker-related VMs subsequently. The Kitematic-spawned b2d VM seems to have gotten a new IP in the process somehow and then certificate is valid for 192.168.99.101, not 192.168.99.100. Running docker-machine regenerate-certs default resolved successfully.