Show HN: Anchor – developer-friendly private CAs for internal TLS (opens in new tab)

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

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.

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.

Indeed, we automatically build language (JS, Go, Ruby, Python soon) and OS (debian) packages that you can use in your application or base image. Those packages bundle the set of root CA certs so that your clients trust the certificates presented by servers. Soon we'll have automatic package publishing, so that rotating cert material is just another dependabot PR.

edit: for the laptop problem, we have a CLI toolchain that gets your development environment setup by adding all the necessary CA certs to your local trust store. More about that here: https://blog.anchor.dev/getting-started-with-anchor-for-loca...

The internal TLS stuff built into Caddy is great, as is it's support for ACME. And using Anchor with Caddy has few extra advantages. We generate system & language packages for your clients so they trust the server cert. The dashboard provides a view into all the cert material in your environment. And we have built in maintenance schedules for rotating certificate material. And we constrain the CAs to minimize the risk of key leaks: https://blog.anchor.dev/blast-radius-certificate-constraints...

Yes, this is both "hosted" and "internal": we build & manage a CAs per org. It's a bit like having an instance of Let's Encrypt, but just for your org (or per environment). Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. For example, even if a certificate was issued for gmail.com, it wouldn't be trusted by your clients.

We always build two-tier PKIs, which means your server certificates are issued by intermediate certificates, and those intermediates are issued by a root certificate. In the future, we will let users bring their own root certificate so that we never see your root key material, which you can keep safely in an HSM or KMS.

This is a managed SaaS solution, not self-hosted software like the ones listed. We're more akin to one of the certificate management products in cloud providers, but our target users are not security experts with prior PKI/X.509 deployment experience. We're building anchor for developers who want or need TLS/HTTPS, but don't want the headache & toil of manually setting up & running an internal CA and the extra infra that goes with it.

We don't have a paid offering yet. Right now we're focused on local development environments, which is free to use as individuals and organizations. In the future, we'll have a paid offering for organizations to use in their staging/production environments. Anyone interested in being a part of that pilot, please email me: my-username at anchor.dev

oops! Sorry about that, should have a fix for that soon. In the mean time, here's the correct url: https://docs.anchor.dev/getting-started/quick-start