Readit NewsWith 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.
a) impersonate the identities of your users and b) decrypt the SSL traffic of your users
?
Anchor never see sees your private keys for certificates.
We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
We have a more technical overview of how this works in our docs: https://anchor.dev/docs/public-certs/acme-relay
> The CSR relayed through Anchor does not contain secret information. Anchor never sees the private key material for your certificates.
The closest thing is maybe described (but not shown) in these posts: https://blog.daknob.net/workload-mtls-with-acme/ https://blog.daknob.net/acme-end-user-client-certificates/
(disclamer: i'm a founder at anchor.dev)
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.
It's 100% free, try it out at <https://lcl.host/>
Or, skip the marketing and run this instead:
$ brew install anchordotdev/tap/anchor
$ anchor lcl
As well as demo video: https://www.youtube.com/watch?v=ilLiAabWa4g
We are asking for feedback on our features for teams features for local HTTPS, and would like to hear your thoughts & questions. Many thanks!
I'm sorry. But do you really need to re-invent the wheel yet again ?
Go to the Let's Encrypt website, there is a whole page of client implementations[1].
What makes yours better than, for example, `lego` or `caddy` or `step` ?
All of which are easy to use, come with sensible defaults and do not provide you with "innumerable ways to shoot yourself in the foot".
And for people who really can't use Let's Encrypt because "its difficult", there are still all the old-school, well-established, commercial CA's out there who will hold your hand in return for a few dollars.
[1] https://letsencrypt.org/docs/client-options/
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.