Skip to content
This repository has been archived by the owner on Jul 3, 2021. It is now read-only.

Certificates should be configured with their usages explicitly set #321

Open
tvs opened this issue Jun 28, 2018 · 2 comments
Open

Certificates should be configured with their usages explicitly set #321

tvs opened this issue Jun 28, 2018 · 2 comments

Comments

@tvs
Copy link
Member

tvs commented Jun 28, 2018

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
Copy link

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
Copy link

xyloman commented Aug 10, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants