benburkert

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.

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

sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?

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.

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)

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

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!

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.

We just released a fix for the version error, this will be the last one you see, we promise!

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.

We just see a whole lot of downside and no upside, what reason would someone have other than spoofing a third party domain?

I don't think I understand your second question, are you asking about cross-signing?

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.

Yes, we do support wildcard certs (and will support IP certs in the future). But we don't let you provision certs for domains that you don't own.

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.

Yes, this is both "hosted" and "internal": we build & manage a CAs per org. It's a bit like having an instance of Let's Encrypt, but just for your org (or per environment). Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. For example, even if a certificate was issued for gmail.com, it wouldn't be trusted by your clients.

We always build two-tier PKIs, which means your server certificates are issued by intermediate certificates, and those intermediates are issued by a root certificate. In the future, we will let users bring their own root certificate so that we never see your root key material, which you can keep safely in an HSM or KMS.

We did do some research a few months ago, and I don't remember flagging this Chrome issue. It could either be because we add the name constraints to the intermediate CA certs (we always setup a two-tier PKI), or because our tooling adds the certs to the system trust store (same as mkcert, which IIRC also adds name constraints), not importing them directly into the browser. Other than some issues with Rust's webpki crate (which they have since fixed), I don't recall any client compatibility issues with name constraints. Support was added to OpenSSL around the same time that SNI names were added, so we think of them as roughly the same level of support, which is pretty good in 2023.

I don't have a solid answer, but my hunch for why BetterTLS doesn't place much emphasis on Name Constraints is because they have very limited use in public CAs. The latest cacert.pem bundle from curl only shows 141 certs with name constraints: `curl -s https://curl.se/ca/cacert.pem | certigo dump --json --format PEM | jq '.certificates[] | .name_constraints' | wc -l`

Indeed, we automatically build language (JS, Go, Ruby, Python soon) and OS (debian) packages that you can use in your application or base image. Those packages bundle the set of root CA certs so that your clients trust the certificates presented by servers. Soon we'll have automatic package publishing, so that rotating cert material is just another dependabot PR.

edit: for the laptop problem, we have a CLI toolchain that gets your development environment setup by adding all the necessary CA certs to your local trust store. More about that here: https://blog.anchor.dev/getting-started-with-anchor-for-loca...

Yes, can certainly delegate cert-manager to a CA in Anchor, which gives you a nice view into the cert material in use in your environment. And the client package support automates the toil of updating all your apps or images trusted root CA certs.

The internal TLS stuff built into Caddy is great, as is it's support for ACME. And using Anchor with Caddy has few extra advantages. We generate system & language packages for your clients so they trust the server cert. The dashboard provides a view into all the cert material in your environment. And we have built in maintenance schedules for rotating certificate material. And we constrain the CAs to minimize the risk of key leaks: https://blog.anchor.dev/blast-radius-certificate-constraints...

Hi, author here. I've also done the self-signed cert in dev thing a bunch of times, and never really feel like it provides solid dev/prod parity for TLS in staging & production. And most certificate management products don't work well in development. One of our goals is to make certificate provisioning the same for all environments (including development), so that you can be confident that encryption that works in local development will work the same in staging & production.

oops! Sorry about that, should have a fix for that soon. In the mean time, here's the correct url: https://docs.anchor.dev/getting-started/quick-start

I wonder if he gave Rubinius a go before switching to C++. IANAGD, but i'm guessing some of it's features would benefit game engines: Tunable GC, profiling (http://rubini.us/doc/en/tools/profiler/), JIT/LLVM. It wouldn't solve the C extension problem (maybe FFI does?) or distribution though.

AFAIK there's no way to initiate TLS over a SPDY stream (i guess SPDY could be extended to add TLS handshake control frames, but that's downright crazy) which would mean that the third diagram is misleading. End to end SSL would not be possible with a SPDY proxy. Instead, the client's SSL connection would extend to the SPDY proxy, and the proxy would have it's own SSL (HTTP, HTTPS or SPDY) connection to the remote server. If that's the case, the proxy would have unencrypted access to all traffic.

This is arguably not a problem for clients that explicitly opt in for this sort of proxy setup. But it sounds like this is not the case for the Kindle Fire. Based on this article (i don't have a Kindle Fire to test this theory), i'm guessing the browser has custom CA's for the SPDY proxy so that the SPDY proxy can spoof any domain through the magic of SNI. If all this is true, then it's pretty evil. People who know enough to check for the "secure connection" badge in the browser would be fooled into thinking they have end to end encryption to the website they are viewing. In reality, the proxy, and whoever runs it, silently has complete access to your unecrypted traffic.

There's quite a few assumptions here. And I'm not a SPDY expert so I may be overlooking something. But this doesn't sound like an optimization i'd be comfortable with.

I recently switched from screen to tmux; this is the killer feature for me. We use tmux to pair program with remote employees, and this allows us to stay in sync automatically. With screen, we constantly had to tell the other pair which window we were looking at, which was a constant distraction. It also makes it easy to 'screencast' with multiple remote people.