[paranoidrobot]

Adding CAs to trust stores on devices and in apps is a major pain.

If you have unmanaged devices this becomes even more painful.

"Oh, hi, welcome to the company, please install this Root CA onto your machine to access <internal service>"

Because you can't scope CAs to specific domains, this causes everyone with any idea about security to start being concerned.

[layer8]

Where I work, having internal services be accessed by employees’ own, unmanaged devices would be a no-go anyway. It would be considered a huge security loophole.

[tgsovlerkhgsel]

You can scope CAs with name constraints. However, I believe many implementations ignore constraints on root CAs. Not sure if there is some practical way with cross-signing around that (giving users the choice between trusting your CA and creating their own and cross-signing your CA with that).

[jpace121]

I looked before I started using Let’s Encrypt for some internal stuff and there really isn’t a way to use name constraints in a practical way with modern web browsers at this point. If you’re not using a browser, things get a lot easier, but for browsers you sort of got to suck up that you can’t really avoid the “big” internet.

[msm_]

There is a way, I've recently generated my own CA with domain name constraint, trusted it, and used it cross sign my company's self signed CA. It works like a charm.

[bostik]

As sibling poster already wrote, technically you can scope a CA to a set of subdomains only. Or try. The spec entry is "nameConstraints" but for a number of reasons it may not be well supported.

Some of those reasons are absolutely hilarious. I needed to set up an internal CA back in 2015, and wanted to limit the blast radius in case the private key was leaked. (Usually a "when", not "if" scenario.) I learned about the nameConstraints field and tried to use it. OpenSSL would ignore the key in a CSR input file. Okay, fine, the spec has an OID for the field so I reached for the nearest ASN.1 library to construct a modified CSR with the field in place.

OpenSSL broke trying to parse the file. Go's implementation blew up with a magnificent trace. I gave up and the internal CA was generated with a global validity scope.

I later learned that apparently Microsoft's PKI libraries had support for scope limits, but the feature was not used in real life. Likely because if such a thing came into contact with anything else in the wild, the underlying libraries would just implode.

If you had a self-signed client cert with a nameConstraints in the supplied CA chain, you could probably still crash a non-trivial fraction of web servers.

[tikkabhuna]

> OpenSSL would ignore the key in a CSR input file.

OpenSSL by default ignores many (/all?) extensions for security. You can still manually add the nameConstraints when signing the CA cert.

https://security.stackexchange.com/a/150175

[numpad0]

Will HSTS on a random cert work? Click to accept once, pinned thereafter, or do browsers ignore that for untrusted certs?

[Thorrez]

That's not HSTS, that's TOFU.

HSTS is about remembering to do an http:// -> https:// redirect. It's not about remembering a cert.

The downside of TOFU in browsers, is that it trains users to always click through cert warnings. Train them to do it once, and they'll click through it again when there's a real attack. The warning is the same on the first time visiting the site and on a later time visiting it if the cert has changed.

The TOFU UX in SSH is better, because it displays a different warning for when SSHing to a site for the first time vs SSHing to a site again and the cert has changed.

https://en.wikipedia.org/wiki/Trust_on_first_use

[dspillett]

Many of our clients send automated updates for our systems for data managed in other services via SFTP. It surprises me that few seem to bother verifying the host fingerprints, just blindly accepting them on first connection, given how paranoid they are (quite rightly, the data contains staff and customer information) otherwise.

[eastbound]

Every single company does it. The 3 of them: Asking employees to install a CA, using it for “.internal” resources, then ask employees to use a web proxy and MITM their connections. And optionally, leak the CA’s pk to get pawned. It’s the standard operating procedure of any well-run business.