Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running one’s own root Certificate Authority in 2023

wejn.org

Post reply on HN
Print view View original

111–120 of 164 posts

Re: Running one’s own root Certificate Authority in 2023

#111

Post by xg15 »

cpach wrote: post #103
xg15 wrote: post #34

Earlier quoted context omitted.

Huh, that's odd. Gonna test this as well then.

I think it’s the mixing of HTTP and HTTPS that most browsers doesn’t like. If you develop locally and it’s only HTTP with no HTTPS, then I think it works.

I always thought that "mixed content" was defined as mixing "secure" and "insecure" origins (where a "secure origin" could be either https://something or http://localhost) and not literally mixing http and https urls. But this would explain the problem.

To my knowledge, https on loopback doesn't give you any kind of added security: Everything with enough privileges to capture the encrypted packets on loopback also has enough privileges to just capture the unencrypted memory directly. And "localhost" is also a single "domain", so a cert wouldn't even give you the ability to distinguish between different origins (as other ports or hostnames that resolve to 127.0.0.1 would do)

So it's just some buerocratic hoops to jump through to satisfy browsers.

Edit: I remember reading about some objection that the "localhost" domain could be resolved to something other than 127.0.0.1, either through the hosts file or through a faulty DNS resolver.

I think those objections were addressed in the "let localhost be localhost" proposal which mandated that the hostname "localhost" must be hardwired to 127.0.0.1 in the OS/browsers/resolvers etc and must never be permitted to point to anything else.

But maybe this proposal didn't gain traction and so browsers are defending against such rebound localhost domains.

In that case, I'd try and check if "http://127.0.0.1" works, as the IP address can't be rebound in the same way as the hostname.

Edit2: And of course there is the issue with everything that is defined on top of TLS itself, e.g. ALPN and HTTP2. If you want to test anything involving that, you'll of course need to run TLS on localhost and are gonna need a cert too.

Re: Running one’s own root Certificate Authority in 2023

#112

Post by woodruffw »

ithkuil wrote: post #99
capitol_ wrote: post #98

Earlier quoted context omitted.

It would be impossible to enforce that issued certs are submitted to certificate transparency logs and this would break the security model around the ca system.

Wouldn't the name constrain address this?

It would address the policy side, but not the transparency side (which is arguably critical to the Web PKI’s current security model).

Re: Running one’s own root Certificate Authority in 2023

#113

Post by jiggawatts »

rad_gruchalski wrote: post #110
jiggawatts wrote: post #66

Earlier quoted context omitted.

I get that you don't get it... that's my point. A public-private key pair is clever cryptography, yes, but INTERNALLY within a network they're not Magic(tm) that requires a multi-billion dollar market cap company to issue with some Indian call centre verifying my identity papers. The same cryptographic algorithm has two wildly different uses: one that is $0.0000001 in value, and one that requires a third party organi…

> People conflate the two and then try to charge $50 for the $0.0000001 use-case Then… don’t buy certificates? Use letsencrypt or run your own CA? There are tons of options out there.

You can't use Let's Encrypt for private DNS zones in the general case.

"Running your own CA" like it's a big ceremony is precisely what I'm saying ought not to be necessary.

Do you "run" your own random password generation service PaaS with custom Kubernetes controllers and everything? That's what someone else suggested, and not in jest!

Re: Running one’s own root Certificate Authority in 2023

#114

Post by op00to »

gclawes wrote: post #41
jordemort wrote: post #17

I really like step[1] and step-ca[2] for this, it's a lot less fiddly than having to drive OpenSSL directly. 1. https://github.com/smallstep/cli 2. https://github.com/smallstep/certificates

And they support ACME. I've been running a smallstep CA off of a Nitrokey HSM 2[1] w/ PKCS #11 for my homelab for a few years now 1. https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-...

Can you please give bullet points of your CA setup and more broadly your home lab? It sounds … awesome.

Re: Running one’s own root Certificate Authority in 2023

#115

Post by withinboredom »

jimmyspice wrote: post #105
withinboredom wrote: post #101

Earlier quoted context omitted.

Dear god why? People using ports (even on ::1) is super annoying when it collides with development. Hunting down the offender is not always straightforward and introduces a new failure mode for you (when I’m already using that port for something else). Also, it opens the door for literally any other software (or xss attacks) to connect and issue api calls you may not expect. Just create a native app. Use something li…

what's wrong with using a dynamically allocated port?

How do you have a dynamic port assignment and know how to connect to it without publishing it somewhere? As far as I know, that is impossible.

Re: Running one’s own root Certificate Authority in 2023

#116

Post by vbezhenar »

capitol_ wrote: post #98
infogulch wrote: post #88

Earlier quoted context omitted.

Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore. [2] Then stick it in step-ca and is…

It would be impossible to enforce that issued certs are submitted to certificate transparency logs and this would break the security model around the ca system.

I don't understand the difference between wildcard certificate and intermediate certificate.

Intermediate certificate is more secure because you can use different certificates for different subdomains, insead of sharing private key for wildcard certificate with every subdomain server.

Whether it hits CT or not - is not relevant at all. What matters is if intermediate certificate hits CT.

Re: Running one’s own root Certificate Authority in 2023

#117

Post by firesteelrain »

wejn wrote: post #82
firesteelrain wrote: post #49

HashiCorp Vault supports being an ACME server. Why not use that?

Because: 1. ACME is a dumpster fire prone to mitm attacks. 2. without HSM (an additional investment) it's super bad idea to host your root CA signing key somewhere.

This is an internal, airgapped network.

We stood up the root CA, created the certificate, imported it, then destroyed the root CA. It’s a common security practice. Root CA can then never be compromised

Re: Running one’s own root Certificate Authority in 2023

#118

Post by nickf »

vbezhenar wrote: post #116
capitol_ wrote: post #98

Earlier quoted context omitted.

It would be impossible to enforce that issued certs are submitted to certificate transparency logs and this would break the security model around the ca system.

I don't understand the difference between wildcard certificate and intermediate certificate. Intermediate certificate is more secure because you can use different certificates for different subdomains, insead of sharing private key for wildcard certificate with every subdomain server. Whether it hits CT or not - is not relevant at all. What matters is if intermediate certificate hits CT.

A wildcard covers one single level of sub-domains. An NC'd CA can be used to issue for anything. Nameconstraints are 'enforced' on the client side and many don't support it. Running a public CA - even with a nameconstrained CA, is a challenge to do properly.

Re: Running one’s own root Certificate Authority in 2023

#119

Post by nickf »

jiggawatts wrote: post #64
Nextgrid wrote: post #61

Earlier quoted context omitted.

The main advantage is that this CA and all downstream certificates would be globally-trusted (limited to the domain), which is not the case for a custom CA. Security-wise it shouldn't be any worse than wildcard certificates which are already a thing. It would actually improve things, because the user can now issue downstream certificates much more granularly without having to interact with the root CA (so you can iss…

It would improve things for everybody but the certificate authorities. They're selling something with a marginal cost of zero for $50 each. A wildcard certificate costs more not because it is materially different or "harder" to issue, but because it replaces many $50 certificates. Thus, it "must" cost more, or everybody would just use wildcard certificates everywhere and reduce profits at the large public CAs. It is…

I made a comment up-thread, but name-constrained CAs can issue for anything. It's enforced client-side, and not supported in far, far too many places to work. You'd be giving everyone the ability to issue for anything. Not to mention that running any kind of public CA is harder to do properly than most people thing.

I get the negativity towards public CAs, but much of what you said isn't quite right, either.

Re: Running one’s own root Certificate Authority in 2023

#120

Post by michaelt »

infogulch wrote: post #88
jordemort wrote: post #17

I really like step[1] and step-ca[2] for this, it's a lot less fiddly than having to drive OpenSSL directly. 1. https://github.com/smallstep/cli 2. https://github.com/smallstep/certificates

Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore. [2] Then stick it in step-ca and is…

> Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, [...] intermediate CA

Unfortunately, name constraints don't work in all clients. Name constraints are an 'extension' to the standard and supporting them is optional.

According to [1]

> Before relying on this solution to protect our users, we wanted to make sure browsers were really implementing Name Constraints verification and doing so correctly. The initial results were promising: each of the browsers we tested (Chrome, Firefox, Edge, and Safari) all gave verification exceptions when browsing to a site where a CA signed a certificate in violation of the constraints.

> However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. [...] The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.

And even if someone went around and fixed every TLS library in the world, there'd still be millions of devices out there that never get security updates, like smart fridges and ancient android tablets.

There's a major chicken-and-egg problem: Because nobody will issue name-constrained certificates, clients don't have much reason to prioritise it as a feature. And because name constraints don't work perfectly everywhere, nobody will issue name-constrained certificates.

I doubt we'll ever see a trusted CA issuing name constrained intermediate CA certificates.

Of course, they could offer an API where if you've passed auth for *.example.com you can issue a cert for any subdomain below that without any further validation...

[1] https://netflixtechblog.com/bettertls-c9915cd255c0

Post reply on HN