[GH-ISSUE #131] Support for Name Constraints? #76

New issue

Closed

opened 2026-02-25 22:32:32 +03:00 by kerem · 2 comments

kerem commented

2026-02-25 22:32:32 +03:00

Owner

Originally created by @tisba on GitHub (Feb 6, 2019).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/131

Hi!

I was wondering if there is any support for the Name Constraint extension? I admit I only took a quick look but wasn't able to find anything in regard to this in mkcert.

Background: I would like to constraint the authority of the CA certificate generated by mkcert to be restricted to *.lab.tisba.de or *.lab.localhost etc. There seems to be a growing support for this extension (Chrome does support it for some time, OpenSSL as well and I think it should also be supported by Edge/IE and Safari, maybe even more platforms).

If the private RSA key for the generated root CA could be password protected, combined with name constraints could greatly help to protect from misuse.

If this all makes sense, and you would accept a PR on that topic, I'd be happy to give this a try.

Thank you for mkcert! 💕

Originally created by @tisba on GitHub (Feb 6, 2019). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/131 Hi! I was wondering if there is any support for the [Name Constraint](https://tools.ietf.org/html/rfc5280#section-4.2.1.10) extension? I admit I only took a quick look but wasn't able to find anything in regard to this in `mkcert`. Background: I would like to constraint the authority of the CA certificate generated by mkcert to be restricted to `*.lab.tisba.de` or `*.lab.localhost` etc. There seems to be a growing support for this extension (Chrome does support it for some time, OpenSSL as well and I think it should also be supported by Edge/IE and Safari, maybe even more platforms). If the private RSA key for the generated root CA could be password protected, combined with name constraints could greatly help to protect from misuse. If this all makes sense, and you would accept a PR on that topic, I'd be happy to give this a try. Thank you for mkcert! 💕

kerem closed this issue

2026-02-25 22:32:32 +03:00

kerem commented

2026-02-25 22:32:33 +03:00

Author

Owner

@FiloSottile commented on GitHub (Feb 8, 2019):

Hi! Thanks for the issue. I have elaborated at https://github.com/FiloSottile/mkcert/pull/113#issuecomment-459999460 on why I think Name Constraints don't make enough sense for the mkcert use case to take the complexity. Password protecting the root key follows a similar argument on not really knowing what attackers we are protecting against.

@FiloSottile commented on GitHub (Feb 8, 2019): Hi! Thanks for the issue. I have elaborated at https://github.com/FiloSottile/mkcert/pull/113#issuecomment-459999460 on why I think Name Constraints don't make enough sense for the mkcert use case to take the complexity. Password protecting the root key follows a similar argument on not really knowing what attackers we are protecting against.

kerem commented

2026-02-25 22:32:33 +03:00

Author

Owner

@tisba commented on GitHub (Feb 13, 2019):

Thanks for pointing to the commend, I kinda missed that (sorry).

I understand the argument around the added complexity for Name Constraint, especially if mkcerts intended users cannot be expected to understand the impact. This should also be okay, because if I still want that, I can do it myself :)

Regarding protecting the private key, I have to disagree on your argument in https://github.com/FiloSottile/mkcert/pull/113#issuecomment-459999460. Yes, sensitive material should be 0700, but encrypting/protecting SSH private keys is still recommended last time I checked.

I think making the root key password protected (optionally) should have a minimal impact on the user in terms of complexity and usage. If the key is protected, we could simply ask for the password.

@tisba commented on GitHub (Feb 13, 2019): Thanks for pointing to the commend, I kinda missed that (sorry). I understand the argument around the added complexity for Name Constraint, especially if `mkcert`s intended users cannot be expected to understand the impact. This should also be okay, because if I still want that, I can do it myself :) Regarding protecting the private key, I have to disagree on your argument in https://github.com/FiloSottile/mkcert/pull/113#issuecomment-459999460. Yes, sensitive material should be 0700, but encrypting/protecting SSH private keys is still recommended last time I checked. I think making the root key password protected (optionally) should have a minimal impact on the user in terms of complexity and usage. If the key is protected, we could simply ask for the password.