-
Notifications
You must be signed in to change notification settings - Fork 255
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
step certificate sign
add name constraints
#718
Comments
Hi @LecrisUT, one of the reasons that we created templates was to avoid adding flags for all things that can go in a certificate. To do this, you will create a template: {
"subject": {{ toJson .Subject }},
"keyUsage": ["certSign", "crlSign"],
"basicConstraints": {
"isCA": true,
"maxPathLen": 0
},
"nameConstraints": {
"critical": true,
"permittedDNSDomains": [".example.com"]
}
} And run this: $ step certificate create --csr "My Intermediate CA" my.csr my.key
$ step certificate sign --template name-constraints.tpl my.csr root_ca.crt root_ca_key Although it would be possible to create a CSR with the same extension, you will need to encode the extension itself manually and sign with a template that takes the RAW certificate request like this: {{ toJson .Insecure.CR }} This process can be tedious, and I see the case for #717. But at the same time, I see more benefit of adding If we add |
Regarding this part of the issue, using the template we do not preserve the same fields that the csr was requesting right? That's why I was considering better as a flag in order to use it together with About templates, it can be tedious to design one for each use-case, so how about something more similar to how openstack does it. I.e., they provide a giant template with all features they support, then we enable/define each feature by passing nameConstraints:
critical: true
permittedDNSDomains:
- .example.com Another (not exclusive) way to allow these extension is to use jinja modules and add template jinja files that simply override each module section. The only potential confusion there would be, when does the jinja file override the base, and when does it extend. Although, this feature might not even be available in go's engine. |
It actually depends on the template, you can achieve that if you want, my template doesn't do that, but you have access to the CSR using Our templates have already the ability to use variables and replace values on it from a file from a key=value flag. I thought it was available in I can also provide you with a template with all or most of the features if you want. You can always see the JSON tags and types here |
FYI, just added this #719 |
Ok, I think we're almost there.
Isn't that the case for the built-in template? Doesn't the template engine support if expansions? |
Manipulating the JSON directly might be difficult, so it will be better to access the properties you're interested in, e.g. the subject is {
"subject": {{ toJson .Insecure.CR.Subject }},
"extensions": {{ toJson .Insecure.CR.Extensions }},
"nameConstraints": {
"permittedDNSDomains": [".example.com"]
},
"basicConstraints": {
"isCA": true,
"maxPathLen": 0
}
} In most cases, you will not need the extensions in CSR extensions as you can define them in the certificate template. And then: step certificate sign --template my.tpl my.csr root_ca.crt root_ca.key |
Hmm, isn't this a compelling reason to change the behavior of hot
This should cover any ambiguity in the template when fields are not specified: if we want to include them, add |
You can do Scenario 3 too. You can for example loop through all the extensions in the template and include only the ones that you want to use. And just to clarify, with |
Scenario 3 is the opposite. For example, you want to include all the If we wanted to override the But about #719, that should solve most Scenario 3 usecases, but setting
yes |
Hi @LecrisUT, I've added a PR with some of the things we've been talking about, the For example, if you have two labs you can use those flags to customize the automation of different certificates without modifying the template: $ cat intermediate.tpl
{
"subject": {
"country": {{ toJson .Insecure.User.country }},
"organization": {{ toJson .Insecure.User.organization }},
"organizationalUnit": {{ toJson .Insecure.User.organizationUnit }},
"commonName": {{toJson .Subject.CommonName }}
},
"keyUsage": ["certSign", "crlSign"],
"basicConstraints": {
"isCA": true,
"maxPathLen": 0
}
}
$ cat organization.json
{
"country": "US",
"organization": "Acme University",
"organizationUnit": "SecOps"
}
$ step certificate create --template intermediate.tpl \
--ca root_ca.crt --ca-key root_ca_key \
--set-file organization.json --set organizationUnit=Biology \
"Acme University Intermediate CA" intermediate_ca.crt intermediate_ca_key The same is available on |
Hello!
Issue details
Although this can be done via template, it would be more useful to have it in the cli and to have it available to the csr as well (sign the csr as is, but add some constraints).
Why is this needed?
Particularly useful for signing an intermediate certificate offline and limiting it to a subset of domains like in my previous example #717
The text was updated successfully, but these errors were encountered: