Hacker News Reader

Comment by Mister_Snuggles | Hacker News Reader

I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication.

Is there any tool that I can use to help automate this in a reasonable manner?

Ideally, I'd love to see a web version of xca that supports ACME with some controls on how ACME certificates get issued. Bonus points for supporting OCSP as distribution of CRLs is another upcoming pain point.

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

View on HN

Step CA (https://smallstep.com/certificates/) is a small, manageable CA designed for private PKI uses, and it now fully supports using ACME to hand out certificates to your endpoints. That means anything like certbot that can speak ACME can pull private certs from a Step-CA instance.

If you're moving Private Keys you are Doing It Wrong. This is very common in VPN setups (and S/MIME) but still a terrible idea and worth taking the time to figure out how you'll make sure you don't do this.

I'm definitely open to learning how to do things better, and I have no doubt that some of what I'm doing is wrong - after all, this whole thing started as a homelab-turned-homeprod learning experience.

I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resulting signed cert on the server. Is this correct?

What I'm finding in some cases is that there are cases where this just won't work. For example, my QNAP NAS allows me to either create a self-signed certificate (I don't want this, I want it signed by my CA), get one from Let's Encrypt (same issue), or upload certificate, private key, and optional intermediate CA certificate files (and we're back to moving private keys). This is a limitation of QNAP's GUI for sure, but it's not unique to QNAP.

Similarly, I'm not sure how I'd generate the certificate plus private key on an iOS device and submit it for signing (the VPN scenario). This one particularly bothers me because the .mobileconfig file ends up being the key to the castle. Ideally I'd like the client to be authenticated with both a user-specific certificate and EAP, but I don't think iOS supports this. I haven't quite gone very far down this rabbit hole, so it's possible that I'm missing something.

When I finally secure my internal web server (which acts as a reverse proxy for all of my internal services), I'll try the CSR approach for the learning experience. This approach should also work fine on my VPN server.

> I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resulting signed cert on the server. Is this correct?

Yes. The CSR is public information so it's fine to send that somewhere. "Sign it" [the CSR] is a phrase that doesn't entirely reflect what's happening with the relationship between a CSR and Certificate, experts know it's technically wrong but they say it anyway, so don't sweat it but it's probably misleading.

I will try to circle back to see if I have any suggestions for your specific scenarios later.

Thanks!

I'm going to try the CSR route the next time I have to do this and see how that works out. xca seems to handle CSRs easily, so doing this less-wrong should work out fine.

I'm not too concerned about the QNAP scenario - it's consumer gear, so I expect it to lean more towards doing things easily over doing things correctly. The iOS scenario is much more interesting to me since this is something that's more applicable in the real world.

Well, you are mostly correct.

There are ways to distribute keys safely. You can use key derivation or you can set up transport key (yet another key, just to transport session keys). Both methods are allowed by PCI if done correctly.

Unfortunately that's not what typically happens. Setting up infrastructure to transport keys safely is such a pain in the ass that, for SSL/TLS, I always recommend to just generate the key at the site of its intended use.

If you're doing it from the machine where your CA is, and using secure transport, then it shouldn't be less secure than doing the CSR/Sign/Certificate dance.

I mean, it would be nice, especially if you are distributing to other people, but I don't really see a difference if we are talking about uploading cert/keys to servers where you have root access.

My desire to learn how this works still applies.

But if I'm dealing with this sort of thing in outside of my homelab it'd be nice to see how it all works. I figure that learning how the CSR dance works in my homelab will help me understand how it works in the real world.

check out Cloudflares CFSSL https://github.com/cloudflare/cfssl to manage the CA side, its API, and its OCSP

then check out Netflix Lemur for issuing and tracking certs automatically. https://github.com/Netflix/lemur

CFSSL was developed with cloudflare-specific use cases in mind. If you're looking for a general purpose personal CA, checkout smallstep/certificates: https://github.com/smallstep/certificates. Full disclosure, I work for smallstep, but we’re not exactly competitors. Regardless, here’s an external analysis of the two: https://jite.eu/2020/2/17/step-ca/

This looks very nice too! I'll have to look at this one closely, it seems to give me most of what I'm looking for. Thanks!

These both look really good! I'll have to check them out in more detail.

Use a web browser that respects your choices. Your software should work for you, not the other way around.

Users can choose to manually trust expired certs in macOS/iOS, I don't believe that's what is at issue here.

Reply on news.ycombinator.com