Certificates should be configured with their usages explicitly set

[tvs]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

What happened:
Certificate Authorities, client certs, and server certificates generated as part of the default manifest are not (all) configured with usages.

With kubo_ca, we do not set the key_usage, which results in a CA that doesn't have a usage set for keyCertSign or cRLSign:

- name: kubo_ca
  type: certificate
  options:
    is_ca: true
    common_name: ca

...
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                DE:CB:42:53:28:57:05:BF:66:05:E6:30:C3:39:52:A1:60:F2:5A:1A
            X509v3 Authority Key Identifier:
                keyid:DE:CB:42:53:28:57:05:BF:66:05:E6:30:C3:39:52:A1:60:F2:5A:1A
                DirName:/CN=ca
                serial:65:E3:A2:53:FF:A6:40:C7:0D:ED:82:AB:B7:86:49:65:92:48:42:15

            X509v3 Basic Constraints: critical
                CA:TRUE
...

While the RFC doesn't explicitly disallow this, it makes little sense to have a CA that doesn't have at least keyCertSign.

For server certs, we have tls-kubelet, where we do not set extended_key_usage to make it clear that this cert is intended as the server cert for kubelet's API server (e.g. serverAuth):

- name: tls-kubelet
  type: certificate
  options:
    ca: kubo_ca
    organization: "system:nodes"
    common_name: kubelet.cfcr.internal
    alternative_names: []

The same goes for Docker, Heapster, Dashboard, and so on.

What you expected to happen:
Certs should have both their key_usage and extended_key_usage configured and consistent with one another. It's worth consulting both RFC 5280 and the Credhub API.

How to reproduce it (as minimally and precisely as possible):
Deploy CFCR using manifests/cfcr.yml, check the creds either by pulling them from Credhub, looking at them on the VM, or by using something like openssl s_client against the API servers.

Anything else we need to know?:
Cert names in the manifest are confusing. tls-kubelet-client is not a client cert for the kubelet, but rather a cert that kube-apiserver presents when communicating with the kubelet. It's probably worth revisiting the variable names, but the fact that they're also missing their usages only makes it more confusing.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/158703657

The labels on this github issue will be updated when the story is started.

[xyloman]

We believe to be impacted by this when going through this tutorial: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/

Is there a way to work around this in order to complete the tutorial linked above? After approving the request we are not seeing the certificate entering the status of issued.