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.
> We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
That makes no sense whatsoever.
If you have an ACME account key for my domain, of course you can use it to impersonate my domain. You just need to create another certificate. (Which I could detect, but if I know how to do that, I'm probably not going to need your service anyway.)
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.
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.
Certificate transparency logs are likely the only realistic way, but you could make the same argument against your DNS provider. Trust has to start somewhere.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
Seeing how people are worried about third parties issuing certificates, I encourage using a tool to monitor CT Logs. It really makes the fog of war disappear around your certificates.
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.
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.
“Clients in that container won’t trust the cert”. Yeah, there’s the trick.
“service-a.lcl.host:443300“ so when inside the container, won’t that resolve to 127.0.0.1 which is the container internal loopback interface not the docker host’s interface? Hence trying to connect to itself not its sibling.
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.
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.
Thanks. The upgrade command v0.0.15 gives didn’t work for me. In fact the only method I found that would successfully update was to uninstall it, then untap your tap, then reinstall.
Also, I echo the other people saying that the typeface you chose for the website is very difficult to read.
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.
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
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.