3 ms·

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

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.

fearface 3y ago
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.
- nonameiguess 3y ago
  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.
  - robinhoodexe 3y ago
    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.
    - benburkert 3y ago
      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.
- deleted 3y ago
  [deleted]
- benburkert 3y ago
  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.
3np 3y ago
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.
benburkert 3y ago
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.
- deleted 3y ago
  [deleted]
justsomehnguy 3y ago
> 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.
- hamburglar 3y ago
  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.
8organicbits 3y ago
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 https://news.ycombinator.com/item?id=36674224 2. https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert 3. https://blog.anchor.dev/the-acme-gap-introducing-anchor-part-1-of-3-2466ad7e53f6 https://blog.anchor.dev/the-acme-gap-introducing-anchor-part...
- tuwtuwtuwtuw 3y ago
  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.
  - 8organicbits 3y ago
    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.
    - tuwtuwtuwtuw 3y ago
      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.

fearface 3y ago

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.

nonameiguess 3y ago
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.
- robinhoodexe 3y ago
  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.
  - benburkert 3y ago
    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.
deleted 3y ago
[deleted]
benburkert 3y ago
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.

3np 3y ago

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.

benburkert 3y ago

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.

deleted 3y ago
[deleted]

justsomehnguy 3y ago

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

hamburglar 3y ago
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.

8organicbits 3y ago

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 https://news.ycombinator.com/item?id=36674224 2. https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert 3. https://blog.anchor.dev/the-acme-gap-introducing-anchor-part-1-of-3-2466ad7e53f6 https://blog.anchor.dev/the-acme-gap-introducing-anchor-part...

tuwtuwtuwtuw 3y ago
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.
- 8organicbits 3y ago
  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.
  - tuwtuwtuwtuw 3y ago
    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.