Hacker News Reader

Comment by candiddevmike | Hacker News Reader

I'm not sure I understand the value prop. For localhost, you typically just generate a self-signed certificate that doesn't need to be trusted by everyone, as the dev can just add it to their local store. There are also other services that provide ACME certificates for localhost domains, basically what you do for free (I can't find a link to one but it was posted on HN recently).

If you need a trusted certificate for local dev, something like Cloudflare Tunnels is more valuable as you can have other folks access the service.

View on HN

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

What is complicated about local certificate generation?

You can generate one using openssl and then import it to cert store. That's a few minutes of work to create a script and to me seems much less complex than the alternatives of using some third party service. Reminds me of leftpad.

It depends a lot on what you are doing. The Caddy experience is great as it automates the whole process. But if you run Caddy in a docker container or a VM and connect from the host it's manual again. Maybe you've set up the Firefox trust store, but now Java apps can't connect. Your coworker wants to connect, and now your managing trust stores on other systems.

If you need to write a script, then it's already too complex.

Of course it will differ depending on scenario. Let's say I only want certs for local debugging and I use Java. I can create a script to generate such a cert and import in 5 minutes. Since it's for local debugging I don't care if cert is leaked so I can store it anywhere.

Which solution is less complex? I followed OPs link to Anchor but was prompted to sign on using anorher third-party service which is already more complex in terms of rolling out in a medium sized team.

“Your coworker wants to connect”

It’s no longer local development now is it? You are crossing into dev deployment land. Unless you are talking about remote pair programming and setting up a reverse proxy at home to allow your coworker to connect or open some port forwards on your router (in which case, the world can connect).

I’m in the camp that can write a 14 line Golang program that can generate a self-signed cert for whatever you want. Anything that needs a root CA is going to need LetsEncrypt or those god awful mafia-esque geotrust/verisign certs.

The certs should be installed on your OS, not your browser. No trust stores to manage. Firefox will use Windows Certificate store, Mac keychain, Linux /etc/ssl/certs.

For client certificates, you can generate a self-signed <dns-name-dejour> so long as your hosts file points the domain to your container IP or localhost.

It’s not that complicated but it’s not trivial if you don’t understand certificates. Having a SaaS service do this for you I think is overkill. certbot could definitely do this. I think web frameworks should do this as part of their new-project process. Considering the world requires https.

> It’s no longer local development now is it?

I think that's part of the challenge. Your not "doing local development" or "doing dev deployment". Your trying to solve an evolving set of problems. A local CA works for local, but becomes a pain if you ever need something different.

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

It's a really hard problem, and the root store programs do amazing work. The proof is that hardly anyone is even aware exist at all! I've also done the "use LE for internal TLS" setup, and it worked great until I hit API limits and everything came grinding to a halt. There's a few advantages to using Anchor as a drop in replacement for LE:

- we use an EAB token ACME workflow, so no need to set DNS records or expose infra to the internet, just push API tokens to containers and provision certs at container boot.

- EAB tokens are scoped to least privilege rules, so your staging tokens can't be used to provision production certs.

- Certs don't show up in public certificate transparency logs.

> However, if you're already using ACME in production, maybe you'd prefer to use ACME locally?

I just use Let’s Encrypt: https://gruchalski.com/posts/2021-06-04-letsencrypt-certific....

If I need a CA, I go for cfssl.

Fact, I don’t have ACME via my own CA but it’s not necessary anyway if one is using LE.

I echo this sentiment.

I'm not sure a managed service is interesting. The target audience probably mainly wants it fully self-hosted. From quickly skimming the frontpage, quickstart, and terminology it's not at all clear why I need to / want to make an account in order to run / use this service.

Hi, author here. I've also done the self-signed cert in dev thing a bunch of times, and never really feel like it provides solid dev/prod parity for TLS in staging & production. And most certificate management products don't work well in development. One of our goals is to make certificate provisioning the same for all environments (including development), so that you can be confident that encryption that works in local development will work the same in staging & production.

> For localhost, you typically just generate a self-signed certificate

Ah, yes, that [mythical] developer which entire company depends on and he has one self-signed certificate to fulfill all the needs.

Everyone else has many developers running many local and not-local development (and not only development) environments which can have a full access to Internet or be isolated.

> doesn't need to be trusted by everyone, as the dev can just add it to their local store

And this is how the certificate warnings starts to be dismissed without reading and this is how the local self-signed certs find a ways to the local stores of the every computer device in the company.

Yes indeed. Those who think pki is easy only understand that generating certs is easy, and don’t realize that managing trust of your certs is the difficult part. If you are willing to do a bunch of self-signed certs that aren’t trusted by all the right parties, you’re missing half the point of pki.

The core usecase might be to have anchor and a cert-manager in k8s connected to it and then be able to generate valid certificates for non-public services. Also they would use solely private DNS.

You can create a self-signed CA in cert-manager directly already, which has the advantage that the private key never leaves your infrastructure, you don't need to create a login account on some external service to do it, it will work fine behind an airgap, and you can use your existing DNS domain instead of having to use Anchor's "lcl.host" which seemingly requires all of your queries to resolve "private" URLs now have to go to public DNS servers.

Can you elaborate on this? We have some 300 internal APIs on a valid domain. We used to use let’s encrypt, but got rate limited for obvious and fair reasons when we were migrating between clusters. It’s a bit better with zerossl, but we still get 429s when cert-manager is issuing a ton of certs at the same time.

Just wanted to clarify that `lcl.host` is a service that only helps with local development, it's not useful (and shouldn't be used) in staging & production environments. For staging & production, we let customers use a public domain they own, or a special use domain (`.local`, `.test`, `.lan` etc).

Here's how the architecture you described works with Anchor: assuming your domain is `mycorp.it`, you can add it to your organization. Then create staging & production environments. This provisions a stand-alone CA per environment, and the CA is name constrained for the environment (e.g. only `*.stg.mycorp.it` in staging). Each of the 300 APIs can be registered as a service: this provisions an intermediate CA per environment that is further name constrained (e.g. `foo-api.stg.mycorp.it` in staging). For each service in each environment you generate a set of API tokens (EAB tokens in ACME parlance) that allows your automation to provision server certs with the ACME client of your choice. edit: in your case, cert-manager would be the acme client delegating to Anchor.

Yes, can certainly delegate cert-manager to a CA in Anchor, which gives you a nice view into the cert material in use in your environment. And the client package support automates the toil of updating all your apps or images trusted root CA certs.

Reply on news.ycombinator.com