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

121–130 of 164 posts

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

#121

Post by vbezhenar »

nickf wrote: post #118
vbezhenar wrote: post #116

Earlier quoted context omitted.

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.

One of the parents claims that everything supports name constraints now, so my suggestion was with this assumption in mind.

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

#122

Post by suckitsam »

JackGreyhat wrote: post #21

Easy-rsa to the rescue. Been using it for a while, works great and makes life easier :) Link: https://github.com/OpenVPN/easy-rsa Summary from that page: easy-rsa is a CLI utility to build and manage a PKI CA. In laymen's terms, this means to create a root certificate authority, and request and sign certificates, including intermediate CAs and certificate revocation lists (CRL).

It's funny how I go from "YEAH! CA's SHOULD be a quick one-liner!" to "Should laymen be generating Root CAs?" inside of like 10 seconds of scrolling.

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

#123

Post by michaelt »

3np wrote: post #68
Dragging-Syrup wrote: post #65

Earlier quoted context omitted.

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.

Name constraints are an optional feature in the standards. A client can ignore the constraints and be completely standards compliant.

Should the CAs issue intermediate certs that are only secure if a client implements an optional feature?

And even if most web browsers support name constraints properly - who knows if that cheap network webcam does, or that old mail client, or that 20 year old retro PC game?

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

#124

Post by ithkuil »

woodruffw wrote: post #112
ithkuil wrote: post #99

Earlier quoted context omitted.

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).

I thought that the main problem that certificate transparency addresses is the fact that multiple certificate authorities can all issue certificates for all domains (i.e. there is an overlap in the name space).

So when a CA gets compromised in some part of the the world (or gets manipulated by a state actor that effectively runs the CA) somebody could just emit a valid certificate for a domain you control.

In case of private intermediate name restricted CAs, that can be addressed by logging the issuance of the intermedia CAs.

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

#125

Post by 3np »

michaelt wrote: post #123
3np wrote: post #68

Earlier quoted context omitted.

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.

Name constraints are an optional feature in the standards. A client can ignore the constraints and be completely standards compliant. Should the CAs issue intermediate certs that are only secure if a client implements an optional feature? And even if most web browsers support name constraints properly - who knows if that cheap network webcam does, or that old mail client, or that 20 year old retro PC game?

So it may have limited use-cases today if you require full compat for all clients. For example internal controlled networks like discussed in the article.

Just like you presumably already wouldn't issue LE certs when you need to support clients with ancient CA bundles.

How do you think TLSv1.3 ever got rolled out?

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

#126

Post by Nextgrid »

nickf wrote: post #119
jiggawatts wrote: post #64

Earlier quoted context omitted.

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.

The only "safe" way to introduce these would be to make a certificate format that's intentionally incompatible with existing implementations; that way only new implementations (which are aware of the domain constraint) will accept it where as old implementations would just reject the certificate as invalid/corrupt.

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

#127

Post by wejn »

michaelt wrote: post #123
3np wrote: post #68

Earlier quoted context omitted.

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.

Name constraints are an optional feature in the standards. A client can ignore the constraints and be completely standards compliant. Should the CAs issue intermediate certs that are only secure if a client implements an optional feature? And even if most web browsers support name constraints properly - who knows if that cheap network webcam does, or that old mail client, or that 20 year old retro PC game?

This isn’t strictly true.

If you want to uphold the name constraints in your CA cert, mark the field as critical. At that point clients that don’t understand them should fail validation of the CA cert.

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

#128

Post by xg15 »

diarrhea wrote: post #60
sneak wrote: post #40

Earlier quoted context omitted.

Why not register a domain, get a cert for it, and point it at 127.0.0.1? Then nothing can complain.

My router blocks it to protect against DNS rebind.

If it's just for development, you could set it up in the hosts file.

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

#130

Post by wejn »

firesteelrain wrote: post #117
wejn wrote: post #82

Earlier quoted context omitted.

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

If you destroy the CA, how do you issue new certs via ACME?
Post reply on HN