Mkcert: Simple zero-config tool to make locally trusted development certificates
github.com
github.com
Something that I wonder about from time to time is how "done" is mkcert. A lot of its value is in simplicity, so I've rejected attempts to make it more of a toolkit to generate all sorts of certificates (although I see the value in being able to edit the expiration and other fields). The only thing on my TODO is splitting the trust stores out into an importable package for other tools to use. Maybe that will act as a release valve for other use cases.
In a sense, mkcert will never be done because its job is also to keep up with browser requirements for you, but that goes in waves, and not much has changed in the last couple years. (Unlike the first years of mkcert, when things were really a moving target.) Similarly, it has to keep up with new trust stores and ways to install into them, and we might be overdue for a pass of that, but these are not really new features, just maintenance.
Previously:
Mkcert: Tool for making locally-trusted development certificates — https://news.ycombinator.com/item?id=17748208 — Aug 2018 (39 comments)
Show HN: Mkcert – Valid HTTPS certificates for localhost — https://news.ycombinator.com/item?id=18842218 — Jan 2019 (118 comments)
Thanks Filippo!
The only drawback of mkcert is that it makes you forget the steps needed to make a certificate!
Having said that, nowadays I just bring up a local caddy instance and use that. Caddy can set up and use a local CA for development/testing [1]. In my case I'm using caddy on my little public-facing hobby server anyway, so it's convenient to have a similar setup in local dev. If I cared about actually getting at & directly using the certificates myself I'd probably go back to mkcert.
[1] https://caddyserver.com/docs/automatic-https#local-https
I actually wrote about using it on my blog, which has plenty of screenshots: https://blog.kronis.dev/tutorials/lets-run-our-own-ca
It's pretty good for having your own simple CA, self signed certificates or anything of the sort, as well as having a nicer interface for anything that's not one of the ACME providers (e.g. Let's Encrypt) or when you don't need CLI or automation.
Serve your local website on HTTPS with mkcert - https://news.ycombinator.com/item?id=23653455 - June 2020 (1 comment)
Show HN: Mkcert – Valid HTTPS certificates for localhost - https://news.ycombinator.com/item?id=18842218 - Jan 2019 (115 comments)
Mkcert: Tool for making locally-trusted development certificates - https://news.ycombinator.com/item?id=17748208 - Aug 2018 (38 comments)
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.
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.
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.
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.
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?
Depending on the environment, windows can be set to prohibit executing anything that isn't signed....which is annoying on a dev machine building windows executables.
lol @ "dev machine" ?!
openssl c_client -connect localhost ... is also great. xca is also nice, but mkcert is much easier to use.
I can not remember how and where you need to install these certs, but it just about finding where different applications store their trust stores. Lots of them have their own solutions.
Npm has an option in the config that allow you to choose your own ca location.
Your problem isn't with mkcert and mkcert isn't missing support for anything, but with there not being a good, universal way to manage trust stores. That's an independent issue that mkcert can't fix.