Apple devices support the Name Constraint extension just fine. I've deployed a bunch of internal CA's with Name Constraint and Apple's macOS/iOS/iPadOS block certs that are signed for anything outside of the constraints. As is intended.

AFAIK the Apple bug was fixed in macOS 10.13.3 from what I can find online. [1]

[1]: https://security.stackexchange.com/questions/95600/are-x-509...

That's great to hear! I'd only heard secondhand, so I updated my comment to reflect this detail.

Also I found https://bettertls.com publishes details about which TLS features are supported on different platforms over time, and it appears that the latest test in Dec 2021 shows most platforms support name constraints.

With that roadblock evaporated, I think this would be the perfect solution to a lot of organization- and homelab-level certificate woes. I'd really like to hear from a domain expert on how feasible it would be to automate for free public certs, ACME-style.

I'm happy to see that a big name like Netflix is getting behind this. I've been wishing for better Name Constraints support ever since learning how certificates work. Almost every situation where someone currently uses a wildcard could be done better with a name constrained CA cert.

I would love for this to become as widely supported as wildcards so those who choose to use them could do so easily.

Wish it were as simple - ultimately having a name-constrained and publicly-trusted CA is the same as having any publicly-trusted CA and comes with a ton of wonderful burdens like audits.

You're essentially running a public CA at that point, and that isn't easy.

This is not a technical limitation though. It's a policy limitation.

In theory, a name-constrained intermediate for `.example.com` has no more authority and poses no greater risk than a wildcard leaf certificate for `.example.com`. In both cases the private key can be used to authenticate as any subdomain of `example.com`.

But, name constraints are verified by relying parties (the clients and servers that are actually authenticating remote peers using certificates). It's hard to be certain that everything has implemented name constraints properly. This is, ostensibly and as far as I know, the reason CA/Browser forum hasn't allowed name constrained intermediates.

At some point it probably makes sense to just pull the bandaid off.

CABF and root programs allow NC'd CAs - they're just a pain to operate.

The infra itself, keeping up with compliance and root program changes (which happen with more frequency now!), CT logging, running revocation services (not easy at scale). Plus then things to consider like rotation of the NC'd CA. You'd have to rotate at least once a year, perhaps less given domain validation validity periods. You'd also likely need to have the chain ('chain' used loosely, we know it's not really a linear chain) be four deep like: root->CA->your NC'd CA->leaf, 'cos the root should be offline and unless you're not doing these in much volume I assume you'd want to automate issuance and not gather your quorum of folk to sign from the offline roots. That might not be an issue for many, but it certainly is for some.

(Full disclosure, I work for a CA for almost 2 decades and have pretty intimate knowledge in this area, sadly).

It's interesting to hear that there's already a NC protocol today, but most in this thread are aiming at "should" not "can". The point is that a 90-day, name-constrained CA has no more authority than 90-day wildcard cert if both are issued via DNS-01 validation (modulo nested subdomains), so it shouldn't be subject to the same regulations as a public CA with no restrictions (which require CT logging, audits, revocation services, security requirements, etc as you enumerated), or really any more restrictions than those necessary to be issued a wildcard cert. This would be very beneficial for private networks and would have even better security properties than wildcards. Is there any reason why this shouldn't be possible?

> Several comments here mention running your own CA.

You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/

In comparison, have a look at Keystore Explorer: https://keystore-explorer.org/screenshots.html

Technically you can use it to run a CA, i guess, but in my experience it has mostly been invaluable when dealing with all sorts of Java/other keystores and certificates, as well as doing certain operations with them (e.g. importing a certificate/chain in a keystore, or maybe generating new ones, or even signing CSRs and whatnot).

Sure, you can't automate that easily, but for something that you do rarely (which may or may not fit your circumstances), not struggling with the text interface but rather having a rich graphical interface can be really nice, albeit that's probably a subjective opinion.

Edit: on an unrelated note, why don't we have more software that uses CLI commands internally that correspond to doing things in the GUI, but with the option to copy the CLI commands when necessary (say, the last/next queued command being visibile in a status bar at the bottom)? E.g. hover over a generate certificate button, get a copyable full CLI command in the status bar.

Of course, maybe just using Let's Encrypt (and remembering to use their staging CA for testing) and just grokking DNS-01 is also a good idea, when possible. Or, you know, any other alternatives that one could come up with.

I never got why people think using tar is hard. Specify your archive File with f. want to eXtract it? add a x. want to Create it? add a c. Want it to be Verbose while doing that? add a v. if it's gZiped add a z. Granted, j for bzip2, t for listing is less obvious, but with that it's about everything you need for everyday usage and that more than suffices to disarm that bomb.

Here's an example of better UX (subjectively):

  zip my-archive.zip my-directory
  unzip my-archive.zip

(disclaimer: zip/unzip won't be a reasonable alternative for all of the use cases of tar)

Good software doesn't beg that much explanation. And when it does, then either "--help" or just the command with no parameters e.g. "zip" or "unzip" should provide what's necessary. I don't believe that tar does that, but instead overwhelms the user, whereas "tar --usage" is overwhelming.

Here's another comment of mine which serves a precise example of why tar is problematic in my eyes: https://news.ycombinator.com/item?id=29339018

I don't feel like it follows the UNIX philosophy that well either, though i won't argue that it should be much smaller (because it is powerful, although someone might argue that), but that its commands should be grouped better.

That said, maybe things would be more tolerable if we used the full parameters instead of memorizing silly mnemonics, here's an excerpt from the linked comment:

  $ tar --verbose --create --gzip --file=new-archive.tar.gz ./files-i-want-to-archive

tar -xzvf filename.tar.gz

The mnemonic I use:

x - extract

z - ze

v - vucking

f - files

I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress.

We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environments. We've started building out a management UI there, and it does map to the CLI as you've described :).

[1] https://github.com/smallstep/certificates

[2] https://github.com/smallstep/cli

[3] https://smallstep.com/certificate-manager/

I really want to try and deploy smallstep at home but one stumbling block I always hit is deploying the CA (or ideally the mTLS certificate!) to end user devices like phones, laptops etc. Maybe I'm missing something entirely but I think I'd need a full MDM profile or setup for phones/mobile devices. Is this theoretically a lot easier than I'm making it? I'd just need an iPad, iPhone and MacBook.

Apart from that thankyou so much for what you've done and provided for the opensource community. The smallstep toolkit is truly fantastic.

GP's post prompted me to look into LE's ACME server implementation, Boulder [1], but it's pretty apparent that Boulder is not suitable for small scale deployments. But the smallstep "certificates" project seems to be a lot more reasonable for this use-case. Thanks for sharing, I'll definitely check it out!

[1]: https://github.com/letsencrypt/boulder