[nonameiguess]

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]

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]

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.