Limit the allowed domains in certificate requests to be signed

[dices]

Is it possible to only to limit the validity of the domains to just a domain ?

For example I want the intermediate certificate to be able to just sign certificate requests from *.Ihavenoideawhatiamdoing.internal

[dopey]

Hey, @dices, I was actually doing something just like this the other day. The answer is "yes, but ...".

1. Yes! Here is a certificate template that you can use to generate an intermediate certificate:

	"subject": {{ toJson .Subject }},
	"keyUsage": ["certSign", "crlSign"],
	"basicConstraints": {
		"isCA": true,
		"maxPathLen": 0
	},
	{{/* All fields are optional, and all but "critical" can be a string or an array of strings */}}
	"nameConstraints": {
		"critical": true,
		"permittedDNSDomains": ["example.com"]
	}
}

The command to generate the intermediate might look like:

step certificate sign --template-file /Users/max/src/github.com/smallstep/step/.step/templates/certs/x509/intermediate-name-constraint.tpl inter.csr /Users/max/src/github.com/smallstep/step/.step/certs/root_ca.crt /Users/max/src/github.com/smallstep/step/.step/secrets/root_ca_key

Now you can generate valid leaf certificates for the domains *.example.com.

2. But ... You can also generate any other certificate using this intermediate certificate. The catch is that any certificate that does not have a domain name *.example.com will not be valid. Any normal https client and server will not accept that certificate.

Unfortunately, we do not have a way to restrict this at the provisioner level - so before the certificate is created. Maybe that will be an option in the future. But in the mean time, X509 already has means to do this, and we can take advantage by using templates.

Let me know if you have any further questions about the specific steps required to set this up. This short tutorial might be helpful - https://github.com/smallstep/certificates/blob/master/docs/questions.md#i-already-have-pki-in-place-can-i-use-this-with-my-own-root-certificate.

[tashian]

@dopey Re: restricting by domain at the provisioner level, does this approach work? It uses a template to reject cert requests by domain.

[maraino]

@tashian Both approaches work but in a different way. The one using nameConstraints forces a complying client to fail if the DNS is not *.example.com, but the certificate will be created. In your example, the certificate won't be created as it will fail before signing the certificate, showing the message in the template to the client.

[mmalone]

If you really want to lock things down I think the right answer is to probably do both.

1. Use the template mechanism to tell the CA to only issue certificates for a certain domain.
2. Bake the name constraint into the intermediate to prevent someone from bypassing the CA and using the intermediate signing key to create a certificate directly.

The name constraint on the intermediate will not prevent a certificate from being issued (although perhaps we should change this behavior and make step-ca check for name constraints). Rather, the name constraint will cause certificate validation to fail when the certificate is actually used.

Note also that the template constraint is per-provisioner, while the name constraint on the intermediate will apply to all certificates issued off of that intermediate (i.e., it will apply to all provisioners).

We should probably come up with a way to make this easier at some point, but for now these two mechanisms should do it.