(All the below assumes I can read 'Go')<p>Nit picks about these certificates:<p>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.<p>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).<p>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.<p>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.
<p><pre><code> npx tlx-keygen
</code></pre>
- No installation required, npx comes with Node.js and downloads/runs/removes the package.<p>- Generate localhost certs with support for *.localhost, 127.0.0.1 (IPv4), ::1 (IPv6), etc.<p>- Register in operating system trust store (Win/Lin/Mac)<p>- Tested with major browsers (Chrome/Firefox/Safari/Edge)<p><a href="https://www.npmjs.com/package/tls-keygen" rel="nofollow">https://www.npmjs.com/package/tls-keygen</a>
I've been using minica [0] as recommended by letsencrypt [1] and am fairly happy with how easy it was to run and setup. I also like how small it is; I just embedded it in the development scripts of the project.<p>[0] <a href="https://github.com/jsha/minica" rel="nofollow">https://github.com/jsha/minica</a><p>[1] <a href="https://letsencrypt.org/docs/certificates-for-localhost/" rel="nofollow">https://letsencrypt.org/docs/certificates-for-localhost/</a>
FYI, Windows support just got merged: <a href="https://github.com/FiloSottile/mkcert/pull/46" rel="nofollow">https://github.com/FiloSottile/mkcert/pull/46</a>
Hello HN, author here! :)<p>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?<p>And please open an issue if it doesn’t just work on your dev machine!
It's funny how people seem to do the same thing at the same time. I recently made <a href="https://github.com/socketry/localhost" rel="nofollow">https://github.com/socketry/localhost</a> however `mkcert` has lots of good ideas I'm going to "borrow" :)
I've had good luck with caman (<a href="https://github.com/radiac/caman" rel="nofollow">https://github.com/radiac/caman</a>), but it doesn't do any of the fancy certificate installation bits. This looks neat and useful.
No installation required: <a href="https://certsimple.com/blog/localhost-ssl-fix" rel="nofollow">https://certsimple.com/blog/localhost-ssl-fix</a><p>A few clicks and 1 actual command on macOS
For folks interested in the "minimal" aspect of this project, there is a similar one with a <i>single</i> Go file: <a href="https://github.com/jsha/minica" rel="nofollow">https://github.com/jsha/minica</a>
for embedded boxes golang is either unsupported there, or its binary is typical over-sized, a bash or C version of the same functionalities will be great there.<p>then you can have letsencrypt easily these days so probably we can use 'official certificate' even for local development these days?