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

61–70 of 164 posts

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

#61

Post by Nextgrid »

diarrhea wrote: post #57
gorkish wrote: post #56

Earlier quoted context omitted.

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is fully supported in the standards. Anyone offering this product affordably yet?

Interesting idea. What use cases would this make easier or even possible? At first, it sounds like more work (you’re now your own CA but without full freedom of a truly self hosted one).

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 issue fully offline for an intranet, or issue extremely-short-lived certificates that would otherwise run afoul of root CA's rate-limits).

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

#62

Post by jiggawatts »

diarrhea wrote: post #58
jiggawatts wrote: post #43

“Cultural” technical issues are so frustrating to me. A certificate is fundamentally just a type of credential, like a password, but for historical reasons they’re treated like getting citizenship papers. There’s always this ceremony even in scenarios where it makes zero sense — such as internal-use certificates used for a gRPC API server behind a load balancer. Why - for the love of God why - can’t I just obtain a c…

A password is a secret. A certificate is fully public (it’s useless if not). I don’t see how they’re similar in that dimension. Or how certificates are possible without a third party (a core reason for all the ceremony). Passwords get away with not needing a third party involved because they’re a prearranged process. Certificates aren’t, I need to be able to hit any website at any point, for the first time.

The key phrase here is internal use. Think authentication between two micro services, not HTTPS for someblog.com.

The third party in this case is just a file: the internal CA key.

Try to think of this in the following terms: the issued certs are just signed tokens, nothing more. They’re also conveniently a public-private key pair, but that’s not the point.

The point is that if you used a 1kb random password for service to service auth and someone tried to sell you a $400/mo service to generate them, you’d laugh in their face and then have security escort them from the building.

Sprinkle a tiny bit of cryptography on top and suddenly people think $4,800 annually is a bargain for 1kb passwords.

I can buy a decent used car for that kind of money.

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

#63

Post by matthewaveryusa »

jiggawatts wrote: post #62
diarrhea wrote: post #58

Earlier quoted context omitted.

A password is a secret. A certificate is fully public (it’s useless if not). I don’t see how they’re similar in that dimension. Or how certificates are possible without a third party (a core reason for all the ceremony). Passwords get away with not needing a third party involved because they’re a prearranged process. Certificates aren’t, I need to be able to hit any website at any point, for the first time.

The key phrase here is internal use . Think authentication between two micro services, not HTTPS for someblog.com. The third party in this case is just a file: the internal CA key. Try to think of this in the following terms: the issued certs are just signed tokens , nothing more. They’re also conveniently a public-private key pair, but that’s not the point. The point is that if you used a 1kb random password for ser…

PKI can provide non-repudiation while signed tokens and API keys cannot. There's a big difference transmitting a bearer token vs establishing a TLS connection.

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

#64

Post by jiggawatts »

Nextgrid wrote: post #61
diarrhea wrote: post #57

Earlier quoted context omitted.

Interesting idea. What use cases would this make easier or even possible? At first, it sounds like more work (you’re now your own CA but without full freedom of a truly self hosted one).

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 actually possible to get a domain-specific CA like the one you're thinking of. I saw one at a large department of education. It allowed unlimited issuance of certificates such as HTTPS, mail-signing, document-signing, and some other types that could be locked to a DNS domain. However, there was still a cost per certificate and the up-front cost was huge, something like $100K.

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

#65

Post by Dragging-Syrup »

gorkish wrote: post #56
jiggawatts wrote: post #43

“Cultural” technical issues are so frustrating to me. A certificate is fundamentally just a type of credential, like a password, but for historical reasons they’re treated like getting citizenship papers. There’s always this ceremony even in scenarios where it makes zero sense — such as internal-use certificates used for a gRPC API server behind a load balancer. Why - for the love of God why - can’t I just obtain a c…

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is fully supported in the standards. Anyone offering this product affordably yet?

The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.

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

#66

Post by jiggawatts »

matthewaveryusa wrote: post #63
jiggawatts wrote: post #62

Earlier quoted context omitted.

The key phrase here is internal use . Think authentication between two micro services, not HTTPS for someblog.com. The third party in this case is just a file: the internal CA key. Try to think of this in the following terms: the issued certs are just signed tokens , nothing more. They’re also conveniently a public-private key pair, but that’s not the point. The point is that if you used a 1kb random password for ser…

PKI can provide non-repudiation while signed tokens and API keys cannot. There's a big difference transmitting a bearer token vs establishing a TLS connection.

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 organisation that needs to pay their employees and can maybe justify asking for tens of dollars. (Narrator: Let's Encrypt showed that they can't justify this either.)

People conflate the two and then try to charge $50 for the $0.0000001 use-case, which is a markup of five million percent. That's what's upsetting. It's just so absurd, and people blink slowly and then start suggesting $40 options as-if that discount somehow makes it okay. Or they start talking about "all the things you get" for that $50, when it just doesn't apply.

There should be a trivial set of commands along the lines of:

    New-AzKeyVaultRootCertificate -VaultName 'xyzinternal' -Name 'ContosoAPIServiceRoot'

    New-AzKeyVaultSignedCertificate -VaultName 'xyzinternal' -RootCertificateName 'ContosoAPIServiceRoot' -DnsName 'apisvc1352.internal.cloud'
You can emulate the above with a 20-line script now, but it's fiddly, and doesn't cooperate with Bicep deployment templates. Similarly, there ought to be a built-in renewal mechanism (which is JUST 'cron' for the love of God!), but instead requires Azure Functions, layers of complex authorisations, and who knows what else...

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

#67

Post by gregmac »

diarrhea wrote: post #58
jiggawatts wrote: post #43

“Cultural” technical issues are so frustrating to me. A certificate is fundamentally just a type of credential, like a password, but for historical reasons they’re treated like getting citizenship papers. There’s always this ceremony even in scenarios where it makes zero sense — such as internal-use certificates used for a gRPC API server behind a load balancer. Why - for the love of God why - can’t I just obtain a c…

A password is a secret. A certificate is fully public (it’s useless if not). I don’t see how they’re similar in that dimension. Or how certificates are possible without a third party (a core reason for all the ceremony). Passwords get away with not needing a third party involved because they’re a prearranged process. Certificates aren’t, I need to be able to hit any website at any point, for the first time.

A certificate is a key pair with both a public and private part. The private key is needed to sign data, while the public key can only validate that signature.

You can think of the private key as equivalent to a password, in the context the parent is talking about.

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

#68

Post by 3np »

Dragging-Syrup wrote: post #65
gorkish wrote: post #56

Earlier quoted context omitted.

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is fully supported in the standards. Anyone offering this product affordably yet?

The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.

Like gorkish wrote: No new standards or standard changes affecting any of those necessary. It's only a matter of will and culture on part of CAs.

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

#70

Post by c2h5oh »

gorkish wrote: post #56
jiggawatts wrote: post #43

“Cultural” technical issues are so frustrating to me. A certificate is fundamentally just a type of credential, like a password, but for historical reasons they’re treated like getting citizenship papers. There’s always this ceremony even in scenarios where it makes zero sense — such as internal-use certificates used for a gRPC API server behind a load balancer. Why - for the love of God why - can’t I just obtain a c…

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is fully supported in the standards. Anyone offering this product affordably yet?

Domain limiting is implemented using x.509 cert nameConstraints, which the last time I've checked were not supported on Apple devices..

Edit: has been fixed in osx 10.13.3. Idk about iOS.

Post reply on HN