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

131–140 of 164 posts

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

#131

Post by linsomniac »

goku12 wrote: post #94

Looks like step-ca/step-cli [1] and mkcert [2] have been mentioned. Another related tool is XCA [3] - a gui tool to manage CAs and server/client TLS certificates. It takes off some of the tedium in using openssl cli directly. It also stores the certs and keys in an encrypted database. It doesn't solve the problem of getting the root CA certificate into the system store or of hosting the revocation list. I use XCA to…

Shameless plug, there's also https://github.com/linsomniac/rgca

I've been using it at work for the last year for our certs and it's been quite nice. It can do pre/post hooks as well, so it directly commits the updated CA serial files to our git repo.

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

#133

Post by woodruffw »

ithkuil wrote: post #124
woodruffw wrote: post #112

Earlier quoted context omitted.

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…

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

Yep, that's a "main" thing that CT is intended to address. But it has other useful applications as well: because anybody (including website operators) can monitor the transparency log, they can additionally assert that their own trusted CA is not issuing more than one certificate for the domains they control.

Logging only the name-constrained intermediate CA would make third-party monitoring less useful. It would also have a perverse effect on attacker incentives: the attacker now only needs to compromise a user-controlled CA with a likely to be weaker security posture.

(That being said, maybe these tradeoffs are worth it! I don't have a strong opinion about that, other than my impression that the status quo with Let's Encrypt + intentionally leaking a few private subdomains isn't really that bad.)

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

#134

Post by infogulch »

michaelt wrote: post #120
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…

> 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 corr…

That post is almost 7 years old. My second link is to the test suite mentioned at the end, which if you look at it you'll see that name constraints are now universally supported. I don't think this take is valid anymore.

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

#135

Post by lazyweb »

Anon_Forever wrote: post #129

HashiCorp Vault is a one-stop shop for this. It's an amazing piece of software.

Agreed. I've introduced an internal, selfs-signed CA using Vault, ansible and Jenkins for my personal infrastructure. Issues certs via pipeline job and restarts / reloads affected target services if needed.

I might do a writeup soon on this, it's not even that complicated.

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

#136

Post by infogulch »

woodruffw wrote: post #92
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…

I don’t necessarily disagree, but to point out: issuing an intermediate CA does change the authority model a bit, insofar as it turns a single trusted issuance into a windowed lease to perform arbitrary issuances. On a practical level, the latter is more logistically complex (and needs to be reconciled with other hard-fought battles, like CT). Given that it’s roughly the same as a wildcard certificate in terms of end…

Nobody has ever adequately explained how a wildcard cert presents a meaningfully different security profile than a name constrained CA. Wildcard certs used to identify a subdomain are not logged in CT and nobody is freaking out about it. And if your answer is "because nested subdomains" you should also explain the differential risk of nested subdomains compared to wildcard certs, not fully qualified certs. I don't see how it's meaningfully different.

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

#137

Post by yonran »

infogulch wrote: post #134
michaelt wrote: post #120

Earlier quoted context omitted.

> 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 corr…

That post is almost 7 years old. My second link is to the test suite mentioned at the end, which if you look at it you'll see that name constraints are now universally supported. I don't think this take is valid anymore.

And for old devices, letsencrypt should force nameConstraints to be a critical extension so that old devices will just fail to accept it so that it won't be used “rogue”ly.

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

#139

Post by firesteelrain »

wejn wrote: post #130
firesteelrain wrote: post #117

Earlier quoted context omitted.

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?

Sub CAs or Intermediate CA

The root CA certificate is used to establish trust in the chain of trust, but it is not directly involved in the certificate issuance process once the trust has been established.

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

#140

Post by ithkuil »

woodruffw wrote: post #133
ithkuil wrote: post #124

Earlier quoted context omitted.

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…

> 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). Yep, that's a "main" thing that CT is intended to address. But it has other useful applications as well: because anybody (including website operators) can monitor the transparency log, they can additionally…

Yeah the tradeoff here is that this is intended to replace the use of a wildcard certificate which wouldn't benefit of logging every hostname anyway
Post reply on HN