benburkert

6 ms·

1.
by benburkert 1y 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
2.
by benburkert 1y 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 ne
3.
by benburkert 1y 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 b
4.
by benburkert 1y 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
5.
by benburkert 1y ago
sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?
6.
by benburkert 1y 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.
7.
by benburkert 1y 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)
8.
Show HN: lcl.host for Teams – team-wide local HTTPS in development(lcl.host)
6 points by benburkert 2y ago|2 comments
9.
by benburkert 2y 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
10.
Local cert management for mere mortals(changelog.com)
1 points by benburkert 2y ago|0 comments
11.
by benburkert 2y 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.
12.
by benburkert 2y 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
13.
by benburkert 2y ago
We just released a fix for the version error, this will be the last one you see, we promise!
14.
by benburkert 2y ago
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.
15.
by benburkert 2y ago
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 anch
16.
by benburkert 3y ago
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?
17.
by benburkert 3y ago
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 pub
18.
by benburkert 3y ago
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
19.
by benburkert 3y ago
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.
20.
by benburkert 3y ago
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
21.
by benburkert 3y ago
> 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 vi
22.
by benburkert 3y ago
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 d
23.
by benburkert 3y ago
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
24.
by benburkert 3y ago
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 add
25.
by benburkert 3y ago
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 pres
26.
by benburkert 3y ago
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
27.
by benburkert 3y ago
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 dashboa
28.
by benburkert 3y ago
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&#x2
29.
by benburkert 3y ago
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
30.
Show HN: Anchor – developer-friendly private CAs for internal TLS(anchor.dev)
76 points by benburkert 3y ago|43 comments

More ›