wrhn

Recent submissions

Comment · 1 year ago
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.

Comment · 1 year ago
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.

Comment · 1 year ago
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.
Comment · 1 year ago
It does not.

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

Comment · 1 year ago
sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?
Comment · 1 year ago
No, they stay on the client, our service only has access to the CSR. From our docs:

> The CSR relayed through Anchor does not contain secret information. Anchor never sees the private key material for your certificates.

Comment · 1 year ago
It's 100% possible today to get certs in segmented networks without a new ACME challenge type: https://anchor.dev/docs/public-certs/acme-relay

(disclamer: i'm a founder at anchor.dev)

Comment · 2 years ago
Hi HN! I'm part of the Anchor (https://anchor.dev/) team building lcl.host: <https://lcl.host/>

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
More on teams features here: https://anchor.dev/docs/lcl-host/teams

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!

Comment · 2 years ago
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.
Comment · 2 years ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton