Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

This says it's not meant for production use.

Does anyone know of something that is meant for production use for generating in-house certificate authorities and signing certificates?

I've used scripts I've written myself that run OpenSSL commands. They get the job done, but they're not the kind of thing that fits all use cases, and they're not user-friendly.

I've tried EasyRSA which is not particularly easy either. It requires some unexpected use of environment variables, and I didn't find the documentation very clear either.



I've had my eye on [step](https://github.com/smallstep/certificates) and [step-ca](https://github.com/smallstep/certificates) for a hot minute; it's production quality and seems much more pleasant than the EasyRSA scripts. Haven't tested it but I'd recommend that as a place to start tinkering.


You could use XCA [1] for small scale deployments, or step-ca [2] for a more comprehensive setup.

[1] https://www.hohnstaedt.de/xca/

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


Hashicorp Vault is an obvious one. Microsoft Active Directory Certificate Service is another.

If you're looking for a service-oriented offering, maybe think about Keyfactor, Venafi ... do you already have a PKI that you need to integrate with, etc?


cfssl is what I use, usually a root + intermedia ca, and leaf certs, works really well with cert manager in kubernetes.

https://github.com/cloudflare/cfssl




Using an external service as a way of setting up internal-only certificates? No thanks.


Intuitively this seems reasonable, but, as a sense check I want to put the other side: Not necessarily with the goal that you change your mind, but that you didn't end up just doing what was intuitive without weighing the options.

The public CAs are run pretty well, and they have people actually overseeing them to verify that remains so, without you lifting a finger (well, unless you'd like to help oversee them at least). In contrast a local CA is very likely to be poorly run, because it's not really anybody's actual job to do it properly, you can't justify the expense [If you're Google, then, sure, you can justify the expense but also you are not asking about this on HN] to train them, they can't afford the time and effort to do their best work.

The public CAs are almost certainly not going to lose their root private key, if bad guys do steal the root key for a CA, it'll make news and also you almost certainly aren't the target, in contrast the root key for your private CA probably lives on somebody's laptop (which can be left on a train) or a server somewhere.

There's good tooling for the public CAs. Your software might already come ready to use ACME, and if it doesn't you will find instructions pretty easily. In contrast although there are technology stacks for this stuff without the public CA context, they're not as widespread, particularly in Free Software, and you may find if you need certs for five systems that means five separate tools. Or you do it manually which sucks.

Everything already trusts the public CAs. It's not difficult to tell Mac OS, Windows or even a Linux distro to trust some root CA, but it's an extra step to be done and if you forget it may be difficult to figure out why things don't work. For some services that's enough, but if you also want BYO devices to work that's a nightmare, likewise for guest devices.

Names will almost certainly leak anyway. If your goal is to hide the fact secret-project.example.com exists, I strongly recommend instead changing it to some-codename.example.com so that you needn't care much if the name leaks.

None of the above makes mkcert a bad idea - mkcert is for development. But you should weigh this when deciding whether internal-git-server.mycorp.example should just use Let's Encrypt certificates rather than spinning up an internal only CA.


It's not hard to make a CA.

Make a key for your CA, make an SSL key for your sever, sign the key with your CA and add the CA to your in-house browser/list of trusted CAs.


> add the CA to your in-house browser/list of trusted CAs.

This is the hard part. Unless it's company hardware there is absolutely no way I am installing a new root cert on my machine.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: