Nit picks about these certificates:
The certificates have a lifetime of 10 years starting from the exact moment they're created. I suspect ten years is overkill, but I don't see much real harm in it. However it's common practice to set the notBefore into the recent past, this is because a variety of problems may cause clock drift. This is your development environment, so you _could_ fix any drift, but this sort of tool is all about productivity, so I think "back dating" by one day or even an hour to allow for drift would be a sound idea.
The EKU says TLS Server, I'd be tempted to throw TLS Client in there too. It would appear tempting to say anyUsage, but actually some peers will decide this is overbroad and reject your certificate so don't do that. But having TLS Client might be nice if anybody is working on mutual authentication (both client and server present certificates, not very friendly for B2C apps but I like it in B2B).
The Key Usage says Key Encipherment and Digital Signature. Again it's harmless in a development environment, but security-oriented live systems ought to contemplate removing Key Encipherment.
The only reason you'd need Key Encipherment in TLS is because you're doing RSA key agreement, which means you aren't getting Forward Secrecy by definition and you're probably using some pretty rusty components. So it could make sense to spot that "Oops, we're trying to do RSA key agreement - why?" in a development system before you ship it and discover you're offering radically less security than you expected for some reason.
I was backdating, but I realized a correct notBefore helps identifying when and why you made the certificate. I removed the backdating at the same time as I added the host name in the OU. Nobody has complained so far, so probably not a real problem on dev environments.
I would kind of hope that for client auth you’d have support for a custom root instead of the system pool, hence not needing mkcert (in its current form). But if someone actually finds themselves needing that I’d accept a PR.
Key Usage has been screwed up so much than nearly no one checks them, but in any case I don’t feel like this is the place to fight the RSA key exchange.
npx tlx-keygen
- Generate localhost certs with support for *.localhost, 127.0.0.1 (IPv4), ::1 (IPv6), etc.
- Register in operating system trust store (Win/Lin/Mac)
- Tested with major browsers (Chrome/Firefox/Safari/Edge)
Since many people who run https://localhost are doing front end development node will probably already be there.
[0] https://github.com/jsha/minica
[1] https://letsencrypt.org/docs/certificates-for-localhost/
Something I would love to collect some feedback on is: how would mkcert have to change, if at all, to support a production CA (for stuff like internal machines talking to each other)? Should it even try, or does a tool like minica do the trick there?
And please open an issue if it doesn’t just work on your dev machine!
I mostly used the Ruby C-bindings, and I feel like finding information and documentation was very difficult, and it was even harder to figure out if there was any best practices I was missing.
It baffles me that so important infrastructure is built upon something that feels this brittle, and it keeps me up at night :-)
A few clicks and 1 actual command on macOS
then you can have letsencrypt easily these days so probably we can use 'official certificate' even for local development these days?
it's pathetic, grow up, listen to both sides, technical discussion has its merits, embrace it.
if you're only looking to "this is great" comments at HN, there is no point being here at all.
Yes, some of you will down-vote this, to make your day.
> remember openssl commands you use twice a year
[0] https://docs.microsoft.com/en-us/powershell/module/pkiclient...
This is what mkcert does (FF on Windows not done yet, but FF everywhere else and OS root store is).
> And being package it's better to collaborate on than everyone making their own process (and possibly screwing it up)
Not sure the difference between it being an npm package or a Go project on GitHub is that large. Or are you saying "go build" is easier to screw up than "npm install"?
EDIT: My mistake, misunderstood the context of the comment.
> Not sure the difference between it being an npm package or a Go project on GitHub is that large.
I know mkcert also does this. I also agree that other maintained projects are good too. My comment was in response was to it's parent, which reads:
> So you could use openssl commands and have actually less installation requirements.