Hacker News Reader

Comment by vbezhenar | Hacker News Reader

Browsers always trust manually installed CA roots, because that scenario is used by many corporations to monitor their traffic. OCSP, HPKP, etc won't help.

View on HN

There are more benign uses too - many organisations run an internal PKI, and installing their root CA prevents employees' browsers from displaying warnings about untrusted certificates when accessing internal web apps/sites.

You might be able to make intranet.company-name.tld and have a parking page on the company-name.tld and use that to get a wildcard cert that can be used for the internal pages.

Which you distribute to thousands of people on tens of thousands of devices?

With this you would have a vaild cert for your intranet aka no need to install a self-signed one.

However you would have a single wildcart cert + key that would need to be placed on thousands, or tens of thousands, of machines, by hundreds of staff is dozens of departments.

It would be meaningless.

I can prove ownership and then receive a wildcard certificate for *.internal.company.com, usually by a TXT record or similar (lets ignore EV certs for now), however that certificate isn't an intermediate certificate which is limited to signing new end certificates for blah1.internal.company.com, but wouldn't be able to sign for blah1.not.company.com.

I'm no SSL/TLS expert by any means, so please let me know if I'm wrong and it is fairly easy to get intermediate certificates that are domain name limited - x509 constraints are apparently flakey.

That would be a bad use IMO. Letsencrypt solves any need for legitimate certificates.

Lol. Sure, company sysadmins will run certbot on their mainframes.

There are plenty of clients for letsencrypt, including even Bash ones. That should not be a problem.

Letsencrypt only issues certs for publicly accessible hosts. If you've got a bunch of intranet servers / REST services / whatever that are firewalled from the public internet, you're out of luck.

Thats incorrect, you can verify using DNS zone records, so the server can be as firewalled or air gapped as you want.

> Letsencrypt solves any need for legitimate certificates.

... unless you want any private keys to be personally signed and or generated by bob & alice over in security after checking some boxes in an internal audit form, or any other number of company-internal schemes involving signing and encryption of business-specific data

You're generating private key securely. You're generating CSR which contains public key and signed by that private key and now you need to move that CSR from private location to a public location. But that's not bad, it does not contain anything that could be compromised and your private key is kept safe. Then you're using letsencrypt to issue that certificate using that CSR and keep using that CSR (it does not expire) to renew certificate. All that time private key is kept in safety and is only used by your webserver. Letsencrypt allows you to generate legitimate certificate for internal websites without any compromise on security.

The only use-case that's not possible with Letsencrypt is to issue certificate for IP address.

I don't think it's a bad use. When I logon to my SAN or UPS web interfaces, I don't want to type https://ups01.publicDNSdomain.com, and visit a site with a CT logged certificate. It's an absolutely internal thing and every Active Directory domain already has an (ideally) non-externally resolved DNS domain setup for use. You've already got an internal CA and deployed your own root because there's a series of Microsoft services that work best this way, so it makes a lot of sense to continue to use rather than trying to introduce Lets Encrypt in this scenario.

You don't have to serve that website publicly or even set up DNS records. You only need to set up DNS verification to serve one public TXT record for letsencrypt. Everything else could be internal. Letsencrypt certifies that you own domain. You can do anything with that domain.

I'm aware you can use Lets Encrypt that way, I just don't agree that it's bad use of an internal PKI to use it as an alternative.

Well, it's unnecessary work to install and maintain that internal CA. Keeping CA key safe is very important, because leaked key might lead to your internal connections to, e.g., Google be compromised, so it's like keeping a bomb inside your building. If you already have that internal PKI, you can use it, sure, but I still think that it's a bad idea to use it only for internal websites.

Sometimes you don't want to make that information public though. For security (you don't want to publish your whole tech stack information) and secrecy (you don't want to publish registration of halflife3.internal.valve.com).

Then just use a wildcard cert.

Wildcard certs are a security ops nightmare. You really don't want to throw the private key for that around to every small project, and you need some good, automated way of rolling them across multiple services. Doable, but if you can avoid this, it's a better to avoid.

This 100x - in just about any organisation of any size, if you use a single wildcard cert for all internal services, then it's inevitable that the private key will end up in the hands of an employee that shouldn't have it.

For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.

A lot of internal enterprise networks use MITM, so your app won't work there as well. It might be a good thing or not, depending on your use-case.

Yeah, I considered this a feature. As mentioned elsewhere in these comments, we should have a way to limit the scope of corporate certs.

One solution is to use Name Constraints. The organizational certificate authority could be issued with Name Constraints limiting its power to a certain domain name only, e.g. *.example.com, using Permitted Subtree.

If I was setting up an organizational CA for internal websites (not MITM), I would consider using Name Constraints to limit the certificate's scope and potential for abuse or compromise.

If the app is not for that particular corporation, then no harm done.

Not when the cert has been previously CT and Staple preloaded I suspect?

If a user manually imports a CA, it bypasses protections like CT [1]. This is a feature specifically designed to allow MITM for corporate proxies.

Always seemed like a misfeature to me, but all the browsers do it.

[1] https://chromium.googlesource.com/chromium/src/+/master/net/...

Sounds ridiculous that even when a site host specifically says they want things Stapled and CTd are ignored like that.

Reply on news.ycombinator.com