
Mkcert: Tool for making locally-trusted development certificates - vaibhavmule
https://github.com/FiloSottile/mkcert
======
tialaramex
(All the below assumes I can read 'Go')

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.

~~~
FiloSottile
Hi! Author here.

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.

------
sebastiaand

      npx tlx-keygen
    

\- No installation required, npx comes with Node.js and downloads/runs/removes
the package.

\- 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)

[https://www.npmjs.com/package/tls-keygen](https://www.npmjs.com/package/tls-
keygen)

~~~
vectorEQ
you would need node js installed, so that's atleast 1 installation
requirement... node.js has as one of it's dependencies openSSL. So you could
use openssl commands and have actually less installation requirements.

~~~
nailer
Still sounds good to me - it would do extra stuff like adding it to the
Windows cert store if you're there, adding it to Firefox if you use it, etc.
And being package it's better to collaborate on than everyone making their own
process (and possibly screwing it up).

Since many people who run [https://localhost](https://localhost) are doing
front end development node will probably already be there.

~~~
nickcox
If you're on Windows then you get creating a certificate and adding it to the
cert store out of the box with PowerShell[0].

[0] [https://docs.microsoft.com/en-
us/powershell/module/pkiclient...](https://docs.microsoft.com/en-
us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps)

~~~
nailer
That's really useful - and worth submitting as a separate post.

------
chatmasta
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.

[0] [https://github.com/jsha/minica](https://github.com/jsha/minica)

[1] [https://letsencrypt.org/docs/certificates-for-
localhost/](https://letsencrypt.org/docs/certificates-for-localhost/)

------
kodablah
FYI, Windows support just got merged:
[https://github.com/FiloSottile/mkcert/pull/46](https://github.com/FiloSottile/mkcert/pull/46)

------
FiloSottile
Hello HN, author here! :)

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!

------
ioquatix
It's funny how people seem to do the same thing at the same time. I recently
made
[https://github.com/socketry/localhost](https://github.com/socketry/localhost)
however `mkcert` has lots of good ideas I'm going to "borrow" :)

~~~
Rjevski
I made my own variant of this as well, although it was just config files &
shell scripts wrapping OpenSSL instead of being a custom binary.

~~~
kawsper
Me too, but it was mostly to teach myself about OpenSSL, and I feel like the
experience have scarred me for life.

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 :-)

~~~
blattimwind
Don’t worry, everyone who used OpenSSL APIs feels the same way as you do.

------
beardicus
I've had good luck with caman
([https://github.com/radiac/caman](https://github.com/radiac/caman)), but it
doesn't do any of the fancy certificate installation bits. This looks neat and
useful.

~~~
ausjke
bash-based, looks good to me.

~~~
epcim
cfssl shell wrapper [https://github.com/epcim/cfssl-
pki](https://github.com/epcim/cfssl-pki)

------
nailer
No installation required: [https://certsimple.com/blog/localhost-ssl-
fix](https://certsimple.com/blog/localhost-ssl-fix)

A few clicks and 1 actual command on macOS

~~~
Improvotter
The point of mkcert is so you can use it on any OS without a bunch of hoops to
jump through.

~~~
nailer
Installation of a binary is also a hoop.

------
vectorEQ
is there an advantage to this over using openssl or nss/certutil commands?

~~~
toyg
The main advantage to me would be "not having to remember openssl commands you
use twice a year"...

~~~
daurnimator
Thats why I write a blog post to myself ;)
[https://daurnimator.com/post/115624714644/howto-generate-
a-s...](https://daurnimator.com/post/115624714644/howto-generate-a-self-
signed-ssl-cert-in-one)

~~~
devy
Your blog post was about creating a self-signed TLS cert. mkcert is more than
that, it creates the root CA first before creating self-signed certs and
trusting them.

~~~
daurnimator
Indeed; but I was replying with my solution to the general problem of

> remember openssl commands you use twice a year

------
tedchs
For folks interested in the "minimal" aspect of this project, there is a
similar one with a _single_ Go file:
[https://github.com/jsha/minica](https://github.com/jsha/minica)

------
ausjke
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.

then you can have letsencrypt easily these days so probably we can use
'official certificate' even for local development these days?

~~~
ausjke
i am always puzzled by some of those down-votes, i thought constructive
thoughts are at least welcomed at HN. The fact is at HN unless you are saying
"this is a great idea/project and you're awesome" or be totally neutral, any
other thoughts such as a constructive one, not to mention a critical one, will
always or at least very likely to get a down-vote.

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.

~~~
lysium
It was not constructive. And let’s encrypt does not work for localhost.

------
another-cuppa
Emoji is unnecessary and annoying.

