Skip to content
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

Support SKI in non-CA certificates #13

Closed
matthewvalimaki opened this issue Mar 16, 2018 · 7 comments
Closed

Support SKI in non-CA certificates #13

matthewvalimaki opened this issue Mar 16, 2018 · 7 comments

Comments

@matthewvalimaki
Copy link

matthewvalimaki commented Mar 16, 2018

I would like existing SKI support to be extended to non-CA certificates. For RFC see https://tools.ietf.org/html/rfc5280#section-4.2.1.2. While the RFC says it is mandatory for CA's the way I read it they suggest using SKI with end entity certificates as well.

I came across this with etcd & OpenShift Origin combination where the etcd keys have SKI in the non-CA certificate.

Terraform Version

Terraform v0.11.3

  • provider.tls v1.0.1
@matthewvalimaki
Copy link
Author

matthewvalimaki commented Mar 16, 2018

Here are requirements that OpenShift Origin sets for etcd client certificates

authorityKeyIdentifier = keyid,issuer:always
basicConstraints       = critical,CA:FALSE
extendedKeyUsage       = clientAuth
keyUsage               = digitalSignature,keyEncipherment
subjectKeyIdentifier   = hash

Specifically subjectKeyIdentifier = hash says to generate SKI.

@matthewvalimaki
Copy link
Author

In resource_certificate.go we have createCertificate in which we have if d.Get("is_ca_certificate").(bool) { so I am thinking of adding similar add_ski to allow forcing when wanted. Does this make sense? I could work on a PR for this.

@SpencerBrown
Copy link
Contributor

Agreed that RFC 5280 says that the subject key ID SHOULD be included in end entity certificates.

We could just change the code to always add it. But out of an abundance of caution let's put it behind an option. How about, in the tls_locally_signed_cert and tls_self_signed_cert resources, a top-level argument:

  subject_key_id: true

to force a key ID. Default if cert_signing enabled is true, otherwise false.

@dawidmalina
Copy link

I'm also looking for more options as @matthewvalimaki. What is blocking me from switching fully to this provider is lack of (mentioned) subjectKeyIdentifier: hash but also authorityKeyIdentifier: keyid,issuer:always.

@SpencerBrown any updates on this topic?

@IvanovOleg
Copy link
Contributor

IvanovOleg commented Oct 25, 2018

I have the same issue with kubernetes certs. #31

@detro
Copy link
Contributor

detro commented May 16, 2022

Support for set_subject_key_id is already in place, since #31

@detro detro closed this as completed May 16, 2022
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
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

6 participants