
Show HN: Localdots – HTTPS domains for localhost with autoconfig and hot reload - lfarzati
https://github.com/luisfarzati/localdots
======
timdorr
If you would prefer to listen to TLS directly, or don't want to use Docker, a
great alternative is mkcert:
[https://github.com/FiloSottile/mkcert](https://github.com/FiloSottile/mkcert)

It automates creating a self-signed certificate and having it trusted in your
local cert stores. I've always missed something when doing it by hand, so it's
a great automation tool.

~~~
VvR-Ox
Thank you for the hint. Last time I needed to do this I wrote a script which
basically does the same without being that versatile.

It helped to understand more about local cert storage (e.g. cert9.db) etc. but
I prefer using a tool like this which is maintained by the community and
probably still works some years from now.

~~~
lfarzati
I did the same, localdots started actually as a simple script using mkcert for
solo projects. :)

Unless I'm forgetting something now, the only reason I switched to smallstep
was for ACME support which mkcert lacks for now (see
[https://github.com/FiloSottile/mkcert/issues/154](https://github.com/FiloSottile/mkcert/issues/154)).

I wanted an ACME solution to better automate the server config with Caddy.

------
pritambaral
Does this generate root CAs with NameConstraints[1] set? Because otherwise,
the root CAs could issue a trusted cert for _any_ domain on the internet.

1:
[https://nameconstraints.bettertls.com/#!about](https://nameconstraints.bettertls.com/#!about)

~~~
lfarzati
Thanks for raising this point! Honestly, I'm not sure. Probably not. Given
that localdots is meant to be used only for local development, would this be
considered an important feature anyway? I'm not sure I see the security
concerns here.

~~~
tialaramex
Rather than meddling with putting Constraints on a self-signed root cert, I'd
suggest considering automatically destroying the root's private key after
making any needed certs. That is, the root's private key exists only long
enough to issue certificates for this session, then it's destroyed. If the
user changes things you don't re-use that root CA, you distrust it and make a
new one, for which the private key would likewise only exist during setup and
then be destroyed.

This way the only possible certificates that can ever exist are those created
during setup. After that nobody can sign more certificates because the private
key needed doesn't exist any more, so you don't need to worry about
constraints (which can have compatibility problems e.g. that's why Let's
Encrypt X3 and X4 exist instead of X1 and X2 these days)

~~~
lfarzati
This is excellent advice, thank you.

------
rrosen326
How do people in general test their https during development? I've never done
it but will for my current project, but am dreading it. I was thinking of
Docker or Vagrant. Or maybe this localdots.

This must be a solved problem. How do you all do it?

~~~
benologist
I liked using a service called serveo that just uses SSH but recently it went
offline so I am back to using either ngrok or localtunnel. These let a
remotely-hosted HTTPS domain point to a local port on your computer or server
you just request a URL pointing to local port X.

[http://serveo.net](http://serveo.net)

[https://ngrok.io](https://ngrok.io)

[https://localtunnel.me](https://localtunnel.me)

These are command-line tools with NodeJS libraries, you can run them parallel
to your project or internally. I am using the NodeJS libraries to create a URL
when my tests start. Stripe recently added webhook endpoints to their API so
you can also create webhooks bound to whatever URL you are assigned.

------
swiley
You could just make a CA cert and sign a domain name that you always point to
some RFC1918 non routing address. I’ve never done this because I try to avoid
things that “require https even with localhost” but I’m fairly certain that
would work and all you need is the OpenSSL command.

