localias VS mkcert

I empathize with the author and found the post to be a interesting and concrete example of what it's _actually like_ to try to publish a blog to Mastodon, which is something that I have thought about and read about in abstract. So, thank you sir for writing this up.

One thing to consider would be to try to use Caddy [0], or a tool like localias [1], as a local https proxy. You might be able to run both the mastodon server and your blog software on the same computer and refer to local-only urls like "https://blog.test" and "https://mastodon.test" and have everything work.

I'd be curious to know why the author didn't try this, they seem to be quite knowledgeable of other web technologies so I have to assume there's a problem that I'm not seeing here.

[0] https://caddyserver.com/

[1] https://github.com/peterldowns/localias

Sure, but there are also excellent FOSS solutions for this, such as https://github.com/peterldowns/localias which has the benefit of being cross-platform.

Pretty good overview from Baldur — I don't always agree with everything he writes but this seems relatively correct.

One question I'd ask him (and anyone else reading) is: what are some other options for monetization?

Over the last few weeks I had three different VCs reach out to me about some of the open source projects I've been releasing, and ask me if I'd thought about making a business out of them. I told them that no, based on the problem the software was solving, I didn't see how I could adopt open-core or companion-saas business models, and I wasn't sure how else it could be done while keeping the code open source.

Can anyone suggest a viable business model that would allow:

* Code remains at least source available, ideally open source for non-commercial use.

* I can charge for commercial use.

* Actually doing the licensing is reasonable, ie no spyware or phoning home from the tool.

Wouldn't need to be perfect, I understand that if the code is open source a company could easily fork and use it without paying me. The idea would be to make it zero-headache to pay me for a license if the code is being used by a funded team.

The projects:

* https://github.com/peterldowns/localias

* https://github.com/peterldowns/pgmigrate

The experimental HTTPS flag relies on mkcert, designed for a single development system. If you run a Docker container, the flag won’t configure your local browser to trust its certificate.

The author mentions difficulties with HTTPS and trying stuff locally.

I've had some success with mkcert [1] to easily create certificates trusted by browsers, I can suggest to look into this. You are your own root CA, I think it can work without an internet connection.

[1] https://github.com/FiloSottile/mkcert/

Solution: mkcert – Your Zero-Configuration HTTPS Enabler Meet mkcert, a user-friendly, zero-configuration tool designed for creating locally-trusted development certificates. Find it on its GitHub page and follow the instructions tailored for your operating system. For Mac users employing Homebrew, simply execute the following commands in your terminal:

Well, Certifi does not ship with your company's certificates! So requesting internal services may come with additional painful extra steps! Also for a local development environment that uses mkcert for example!

My project, getlocalcert.net[1] may be the one you're thinking of.

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

Looks like step-ca/step-cli [1] and mkcert [2] have been mentioned. Another related tool is XCA [3] - a gui tool to manage CAs and server/client TLS certificates. It takes off some of the tedium in using openssl cli directly. It also stores the certs and keys in an encrypted database. It doesn't solve the problem of getting the root CA certificate into the system store or of hosting the revocation list. I use XCA to create and store the root CA. Intermediate CAs signed with it are passed to other issuers like vault and step-issuer.

[1] https://smallstep.com/docs/step-ca/

[2] https://github.com/FiloSottile/mkcert

[3] https://hohnstaedt.de/xca/

We use mkcert for this, it works wonderfully.

https://github.com/FiloSottile/mkcert