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

91–100 of 164 posts

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

#91

Post by alexvitkov »

galaxyLogic wrote: post #89

I'm building an app whose GUI runs in the browser talking to a local http server. The app (if and when it is ready) would be distributed as a standalone executable. A bit like Atom/Electron I guess. What I haven't figured out yet is how the browser-GUI could talk to its local backend-server over https. Can an exe contain its own root-certificate-authority somehow in a way that the app-exe can work without having to u…

Why? What's the potential attack you're preventing by encrypting communication of two local processes?

You'd have to install a shady custom CA system-wide on your users, for a green lock that's 100% placebo. Just run firefox/chrome in app mode and hide the URL bar.

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

#92

Post by woodruffw »

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…

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-user use, it’s IMO understandable that this isn’t a priority for the CA ecosystem to support.

(The use case of circumventing CT is probably a non-starter as well. The Web PKI doesn’t want CT loopholes!)

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

#93

Post by toastal »

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

Nice to see open source hardware token usage in the wild.

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

#94

Post by goku12 »

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 create and store the root CA. Intermediate CAs signed with it are passed to other issuers like vault and step-issuer.

[1] https://smallstep.com/docs/step-ca/

[2] https://github.com/FiloSottile/mkcert

[3] https://hohnstaedt.de/xca/

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

#95

Post by goku12 »

remram wrote: post #84

I tend to treat service TLS certificates more like shared keys than PKI. Too many pieces of software don't handle revocation, it's easier to regenerate the CA and the entire set of certificates when you change your setup.

The better solution is to do what vault does. Use only ephemeral certificates for servers and clients. It wouldn't be too hard to change them every week or so using the ACME protocol.

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

#96

Post by goku12 »

galaxyLogic wrote: post #86

Is there an Open Source program I could just run on the command-line, to have my own Certificate Authority? Or just to create a certificate? Or do I need to know all the gory details myself?

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

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

#97

Post by jeroenhd »

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…

There are ways to use internal CA certificates to authenticate microservices, though they're mostly based on Kubernetes. Take Istio's solution, for example: https://istio.io/latest/docs/tasks/security/authentication/m...

Very few people still use TLS client authentication, but it does work. You can definitely get it up and running for less than 400 dollars per month. The magical keyword for Google here is "mutual TLS"

If you're using a Windows based system, you can do this stuff automatically through Active Directory: https://learn.microsoft.com/en-us/windows/security/operating...

The thing is, credential management is very difficult, and people are willing to pay up to solve very difficult tasks. If you build a (non-Kubernetes} certificate management solution, you'll probably want to sell it for big bucks as well. Generating certificates is just an openssl command line on a timer, the difficulty is getting those certificates deployed in the right places automatically. It's all possible through some basic scripting, but to do it right you need to solve more than just the certificate part.

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

#98

Post by capitol_ »

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…

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.

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

#99

Post by ithkuil »

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.

Wouldn't the name constrain address this?

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

#100

Post by kubanczyk »

remram wrote: post #84

I tend to treat service TLS certificates more like shared keys than PKI. Too many pieces of software don't handle revocation, it's easier to regenerate the CA and the entire set of certificates when you change your setup.

If you control all the clients/browsers (i.e. you can immediately modify the required trust stores), you don't have any use for PKI whatsoever.

PKI's use case begins with shipping a trust store into the wild, where it will run unchanged for months or years.

Post reply on HN