I am creating a site with my own CA and signing client certs with it. The clients will need to add my CA as a trusted source, but for security reasons I don't want them to blindly trust everything that could be signed with the CA key, so I want to impose limitations to build clients' trust. So I want to limit the CA abilities to just signing client certs and enabling https access. I am not sure all restrictions I should impose in the cert creation.

The best way to do it seems to be Name constraints, and use a white list to limit the usage, which is apparently respected nowadays. So I though I have to use a dns (let's say xyz.com), so the CA signature would not be accepted for google.com f.ex, and put that also in each SAN of the client certificates, so the client certs are considered valid and not rejected. Apparently that's not how it works. I have tried this but I have not been able to make it work correctly. Also, I am getting a warning from Windows... Maybe it is because all possible name constraint types must be present?

enter image description here

So my questions are:

  1. How should I configure the CA cert? What restrictions should I apply in the CA cert to limit its ability to be misused? If it involves name constraints, why is my example in the image not working?
  2. Is there anything extra that should be done/considered in the client certs, like adding an extra SAN?


Ideally, there should be something in my CA certificate that forces it to only sign client certificates and do the https server authentication. I don't see how to make this limitation, I think it is not possible.

For the use of Name constraints, I have use xyz.com as permitted, and I thought that only certs signed by my CA with SAN xyz.com and actually used by using that name will be accepted (otherwise I could create a certificate with SAN xyz.com and google.com and might work when accessing google.com). So I have used a client certificate signed by my CA with no SAN xyz.com and I was accepted. Not sure if the name constraints apply in this case too.


There are a few constraints that you can set in an issuing certificate, which limits which certificates it can sign.

Name constraints

You have already mentioned those. They can be used to limit which names may be used in the various subject alternative name types of the end certifcate (whitelisting using permittedSubtrees) or may not be used (blacklisting using excludedSubtrees). In practice, the former one is probably which you want. A typical use case would be, to only allow e-mail addresses and dnsNames which end with one of your companies domain names.

This page gives more detail.

Policy constraint

This extension can specify, under which policy an end certificate may be issued. Since this is not something you can really technically enforce (apart from comparing OIDs), this won't be useful to you

Extended key usage

This one is not really a standard usage, but since your screenshot suggest that you are living in a Microsoft world, it could be useful to you. Microsoft invented the so called Application policy which allows a issuing certificate to limit which extended key usages an issued end certificate might have. By setting this policy to tlsClientAuthentication, you can ensure that only such client certificates are issued and no TLS server certificates or code signing certificates. Outside of the Microsoft cosmos, this extension will probably be ignored.

One final word: Checking these constraints is pretty hard, most software don't even bother to try, and there are not a lot of products out which actually get it right.

  • So according to you I have done the right thing with names constraints, but why am I getting a warning? Have I wrongly created it? – user1156544 Jul 6 '17 at 13:04
  • Which warning are you getting exactly from which software? – mat Jul 6 '17 at 13:14
  • You can see in the image, the yellow sign in the Windows certificate tool that opens via Chrome. Also, I made an edit – user1156544 Jul 6 '17 at 13:22
  • The screenshot just shows the windows certificate screen, no warning or error message. – mat Jul 10 '17 at 9:41
  • BTW: A CA certificate should not have a dnsName entry. – mat Jul 10 '17 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.