Live data from Hacker News

Running one’s own root Certificate Authority in 2023

wejn.org

151–160 of 164 posts

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

#151

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…

There's a set of ports allocated for http by the standards. The app will choose to use the first one available, starting with 80. If all such ports are in use then tell the user sorry all ports are already in use. Please stop some apps already running on your PC which may be using these ports.

So you have to run your app as root on Linux and windows firewall is going to have a field day? I don’t know what happens on a Mac, but I assume it will also require root to use low ports. Why not use port numbers dedicated to this kind of thing (1024 – 65535) or better yet, just use pipes and avoid opening a network server at all.

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

#152

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

I completely agree that dealing with openssl is fiddly at best when you RYO CA. But, if your org knows how PKI works it's not a big deal; a bash script or two in the simple case or a flask app at most complex.

If your org doesn't know how PKI works shouldn't you be paying a vendor that does?

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

#153

Earlier quoted context omitted.

One accepts an arbitrary subdomain as a matter of verification policy, and the other has broader PKI implications: how should verifiers handle name constraints with multiple prospective paths? How should they handle CAs that issue longer-lives certificates than the CA/B guidelines permit? CAs that allow end-entity certs with known insecure algorithm choices, etc? In short, allowing user-controlled name-constrained in…

Thanks, I appreciate a response with some substance. > name constraints with multiple prospective paths Can you expand on this for me? Is this really a problem? > longer-live[d] certificates than the CA/B guidelines permit The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired? > known insecure algorithm choices Disallo…

> Can you expand on this for me? Is this really a problem?

Sure, happy to: the issue here is that the user’s root might present multiple prospective validation paths, none of which have to agree on the total constructed set of permitted/denied name constraint subtrees. Path validation also doesn’t impose an order, meaning that two clients can (correctly!) disagree on the set of names that a validation path can issue.

Is it really a problem? Maybe: the various Web/Internet PKI standards aren’t clear about how to handle situations like this, and things that change the Web PKI to rely more heavily on correct extension handling have historically revealed lots of fragile/noncomplying clients.

> Would a cert be valid if the iCA cert that issued it is expired?

Nope, I made a mistake here: this wouldn’t be an issue, for the reason you’ve said.

(Having an ICA that expires every 90 days would impose other logistical challenges, however: you’d either need to include it in the server response along with the leaf, or lean heavily on an extension like AIA to retrieve the current ICA certificate.)

> If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?

Probably no worse for the private network scenario, although I think the proposed solution here ends up confounding the public and private cases: the certs issued under a NC’d ICA would also be valid on the public Internet, and may end up intentionally or unintentionally depending on this behavior.

If I had to TL;DR my opinion here, I think it would be: “all of these things are solvable or addressable at the policy level, but the Web PKI has historically been brittle to assumptions that currently standardized things are correctly respected by the client ecosystem” :-)

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

#154
post #67

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.

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.

Thanks for the clarification. It’s a misuse of that term then. A certificate is not a key pair. A certificate is very clearly and narrowly defined: a statement of the form “this public key belongs to this name” (in this case a DNS name, but can be any name), signed by a (mutually) trusted authority. Once you trust that authority, you trust the connection of name to key.

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

#155
post #83
post #69

"Only" missing how to safely distribute, trust and revoke/renew the root cert - and how to enforce/distribute revocation lists for certs...

"only" out of scope. But based on the comments here, I guess you could use the smallstep CA with Nitrokey HSM if that's your jam...

Well, the title says: "Running one's own root Certificate Authority in 2023".

"Running a CA" is pretty much dominated by managing certificates? Including distribution and revocation - not just issuing?

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

#156
post #96

Earlier quoted context omitted.

mkcert if you need only on one system - usually for development. step-ca/step-cli if you need a CA at residential or office domain. XCA if you don't mind a GUI and know how to get the root CA certificate into the system/browser trust stores. links in this comment: https://news.ycombinator.com/item?id=37542794

Thanks for the links. Let me re-phrase my question slightly: Is there any npm-modules I can install (with npm) which would allow Node.js to automatically serve https?

I'm afraid I don't have a firsthand reply to that question. Sorry! Have you given this a try? https://nodejs.org/api/tls.html#class-tlsserver

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

#158
post #107

I went with DNS based Let's Encrypt for internal certificates, since I'm okay leaking my internal DNS names. > An obvious downside of this is having to guard a bunch of secrets and the need to rotate the host certificates yearly – because Apple says so. The guarding secrets thing makes me too uncomfortable with managing my own CA. I'm sure it'd be fine, but since there are other equivalent and safer ways to do it.. N…

Thanks, I've incorporated the name constraints into the article now. (it is indeed supported by Apple and FF just fine)

Very nice!

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

#159

I eventually need to publish an article about how to run an HSM backed root CA on the cheap with m of n auth. Using nitrokey and some glue scripts you can get the cost below $500. If anyone is interested, let me know.

+1 sounds like an interesting read

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

#160
post #156

Earlier quoted context omitted.

Thanks for the links. Let me re-phrase my question slightly: Is there any npm-modules I can install (with npm) which would allow Node.js to automatically serve https?

I'm afraid I don't have a firsthand reply to that question. Sorry! Have you given this a try? https://nodejs.org/api/tls.html#class-tlsserver

Thanks for the link
Post reply on HN