What does HackerNews think of mkcert?
A simple zero-config tool to make locally trusted development certificates with any names you'd like.
Since I'm also building in this space, I'll give my perspective. Local certificate generation is complicated. If you spend the time, you can figure it out, but it's begging for a simpler solution. You can use tools like mkcert[2] for anything that's local to your machine. However, if you're already using ACME in production, maybe you'd prefer to use ACME locally? I think that's what Anchor offers, a unified approach.
There's a couple references in the Anchor blog about solving the distribution problem by building better tooling[3]. I'm eager to learn more, that's a tough nut to crack. My theory for getlocalcert is that the distribution problem is too difficult (for me) to solve, so I layer the tool on top of Let's Encrypt certificates instead. The end result for both tools is a trusted TLS certificate issued via ACME automation.
1. https://news.ycombinator.com/item?id=36674224
2. https://github.com/FiloSottile/mkcert
3. https://blog.anchor.dev/the-acme-gap-introducing-anchor-part...
[1] https://smallstep.com/docs/step-ca/
Most of the time, you really shouldn't need this, and your local HTTPS development should just require:
mkcert -install
mkcert localhost
If you're deploying private applications, these records should exist in your intranet DNS resolver instead.
It seems to me there's a higher risk that uBlock blocks something and breaks something than uBlock making something work that wouldn't for people not having it. I once had a filter block something called /share/ or share.js, fortunately I noticed during the development. I definitely prefer having it enabled while developing.
> Besides that, you can't get HTTPS for these domains (without the mess of a custom CA and even then you'll run into CT issues)
Indeed. I recently had to do this and found mkcert [1] which makes it very easy to do. But it's overkill for most situations.
mkcert is a simple tool for making locally-trusted development certificates. It requires no configuration.
Using certificates from real certificate authorities (CAs) for development can be dangerous or impossible (for hosts like example.test, localhost or 127.0.0.1), but self-signed certificates cause trust errors. Managing your own CA is the best solution, but usually involves arcane commands, specialized knowledge and manual steps.
mkcert automatically creates and installs a local CA in the system root store, and generates locally-trusted certificates. mkcert does not automatically configure servers to use the certificates, though, that's up to you.I found the steps described in https://github.com/FiloSottile/mkcert reasonable to follow. It describes an iOS workflow too.
I use mkcert[2] for this but it's still fiddly.
[1] https://letsencrypt.org/docs/certificates-for-localhost/
https://blog.filippo.io/mkcert-valid-https-certificates-for-...
https://github.com/FiloSottile/mkcert
to automate setting up local CA and making it trusted.
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.
This is clearly more complicated than ideal, but it should work.
Edit: You can also use a custom CA root certificate, which can be installed on iOS etc. mkcert is a good starting point:
https://github.com/FiloSottile/mkcert
https://turbofuture.com/internet/Intercepting-HTTPS-Traffic-...
[Edit: Now that I think of it, I’m not sure if Squid is really required...]
Some time ago I built something I call “Network Blackhole”.
The project intercepts HTTP traffic from applications that I installed in either my MacBook or iPhone. An excellent example of this is Crashlytics [1], Segment [2], and Sentry [3], which are among a list of popular web services that many developers use to report bugs and crashes in their software, and the famous Google Analytics, which I hope I don’t need to explain what it is used for.
With the help of Little Snitch [4] a popular network monitor for macOS, I detect when an app tries to connect to one of these services, or similar. Then I execute a tool written in Go like so: “blackhole example.com” which does the following:
1. Inserts domain into /etc/hosts
2. Create an HTTP web server (in Go)
3. Adds a match-all endpoint to the server
4. Creates an SSL certificate with mkcert [5]
5. Creates an Nginx virtual-host for the server
6. ???
7. Profit
In the end, and after 1-2 minutes, I have all the traffic to that domain gracefully redirected to a black hole, reducing the amount of data that I leak to 3rd-party websites.
However, don’t get me wrong, I understand the purpose of these services, I haven’t said they are evil or anything like that. I would probably use them myself if I had to, but I certainly would add an alert to ask for explicit consent from the user to send this information to a service that I won’t even have control over. If one of them leaks my customer’s data, I will be the only one facing the consequences.
I hope I don’t have to add another domain to my network black hole anymore.
Chrome finally stopped looking at the Common Name field, and I'm hoping to fade out support in the next few versions of Go. You can already test your systems in 1.11 with GODEBUG=x509ignoreCN=1. Use SANs.
This was one of the motives to create mkcert: https://github.com/FiloSottile/mkcert
https://github.com/FiloSottile/mkcert
It's in pure Go instead of using OpenSSL, and it works with Windows, macOS and Firefox, too.
Still self-signed, but generates a CA that gets added to your browser. It is all pretty seamless.