We don't think of it as reinventing the wheel since it works with all existing RFC compliant ACME clients without needing a plugin. You can use lego, caddy, certbot, cert-manager, or whichever ACME client you prefer.
ACME is great and it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.
Sorry, not trying to obfuscate anything, hopefully this clarifies: users trust us to hold their ACME account key and we only ask for DNS records prefixed with `_acme-challenge.` to be CNAME delegated.
With this we could issue or revoke a new certificate, but we couldn't impersonate them because we don't control the rest of their DNS.
We theoretically could, but those certificates would show up in CT logs. (For quick & easy monitoring, you can get an RSS feed for your domain on https://crt.sh/, but it's not the most reliable service.) It would be a reputation killer if we did that, just like it would be for your DNS provider or ISP.
We launched lcl.host in March as the easiest way to get HTTPS in your development environment, and today we're launching new features to make lcl.host the best local HTTPS experience for development teams.
Before lcl.host, setting up HTTPS in your local development environment was an annoyance, but getting your team to use it is a PITA. That's because practically all tools for local HTTPS work the same way: generate a local CA certificate, install it into the local trust stores, then use it to issue certificates for a localhost domain. They all share a drawback: the certificates are only meant to work on one system. If your team wants to standardize on using HTTPS in development, each developer has to learn the tooling and repeat the same process in their own environment.
But lcl.host works differently: it takes one developer to setup encryption on an app and now everyone has local HTTPS. Instead of individual self-signed CAs, Anchor builds and manages a dedicated CA for your team's development environments.
right it's the loopback, but I believe docker-compose can forward loopback ports to the host (and then back into the other container) using links, but i'm fuzzy on the details and may be misremembering.
we're going to say more about how lcl.host works between containers in the future since it ends up pulling in Anchor's package features, but I can give a quick rundown of what we've done in the past with docker-compose: start a service in container A and expose port 44300, and configure the service with an ACME client to provision a `service-a.lcl.host` certificate. The clients in that container won't trust the cert, but that no problem, since your system/browser will trust the cert if you've run `anchor lcl`. In container B, install an anchor built package for the language of the server, and setup the HTTPS/TLS client to use the set of CAs in that package. Now app B can connect to `service-a.lcl.host:443300` over HTTPS/TLS.
Sorry about that, we're working on switching this to a warning and not an error, that slipped by us before release. After the next update, it will only show a warning if you're not on the latest release.
We install the CA certificates into the trust stores so that the certificates are trusted by your browsers and clients, otherwise they will (rightfully!) get connection errors. We also set the CAA records for all lcl.host subdomains to anchor.dev, so no public CA will issue certificates for *.lcl.host. The only valid certs for lcl.host subdomains you will encounter are for your account's CAs. If we gave everyone a cert+key for *.lcl.host, besides the security concerns, we'd have to keep redistributing them every ~45 days, but with lcl.host you can setup ACME to automatically renew certs before they expire.
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.
It does work, and we've found it to be about as well supported as SAN names, which is pretty extensive these days. It's just not commonly used by public CAs because the real value of these public CAs is that they can issue for any valid domain name, not a predefined set.
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
> 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.
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.
ACME is great and it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.