Show HN: Anchor Relay – A faster, easier way to get Let's Encrypt certificates
22 comments
·August 20, 2025xmprt
I'm sure some people would find this useful but forgive me if I'm not ready to hand away my security to some unknown third party company. I don't know the first thing about CAs but Let's Encrypt really isn't that difficult to understand.
michaelt
I believe the intent here is:
* If you want an SSL certificate for, say, your printer
* And you don’t want to expose your printer’s port 80 to the public internet because you’re not stupid
* And you don’t want to put your DNS credentials onto your printer either, because again, you’re not stupid
* And you don’t want to pay for a certificate with a longer validity, because it’s a home printer, so you’re stitch with monthly cert rotations
* And you’ve embraced the reality that one can delegate SSL not just to CAs, but also to other third parties. Usually the likes of AWS & cloudflare - but why stop there?
Then this product is what you need!
unsnap_biceps
Are there any printers that actually run acme where this is even a consideration?
eternauta3k
Why not sign it yourself?
woodruffw
Most people find the user experience of self-signed certificates much worse. The developer experience for local issuance isn't great, although mkcert does a really great job of smoothing the parts that can be smoothed[1].
toast0
> * If you want an SSL certificate for, say, your printer
Ummmm why does my printer need a certificate?
derefr
If you're already thinking in the IPv6 mode of thought ("every address can be public-routable if it's also default-firewall-policy-closed to packets from outside its network prefix")...
...then — at least in theory — there's no reason to not also give every one of those devices with public-routable addresses, a stable public-rooted name [FQDN] as well.
---
Mind you, none of the infrastructure to make this work exists.
For example, while DDNS exists, it really only exists to assign your gateway router itself a name — with the expectation being that you're using NAT, and then having your router port-forward any interior services to masquerade them as being services of the router.
In a theoretical DDNSv6, meanwhile, you'd be exposing your entire LAN as AAAA records under your DDNS suffix — much like how Tailscale share exposes devices as device.yournetwork.ts.net, but with plain public IPv6 rather than overlay routing.
(But neither routers nor IoT devices have any way to assign DNS-like names to devices on your network. So where would these device names come from? If it were me, I'd have the router observe mDNS announcements from these devices, and then suffix-replace `.local` in the mDNS name with the configured DDNS suffix.)
And then, even if you do that, there's still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. You'd need your gateway router to do L7 IPv6 routing (think "enabling the 'orange cloud' on a record in Cloudflare DNS" — but for your home network) so that the router itself could 1. force itself as the default route for the device, even for LAN packets, and then 2. terminate the TLS connection if the device is being spoken to on port 443; but just act as a dumb passthrough otherwise.
michaelt
Well yes, you've just hit on why this is a rather niche product.
You get a handful of somewhat questionable benefits. If for some reason your guests are visiting your printer's administration page, they won't have to click through a scary warning page. If someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
But the main reason is some homelab enthusiasts are like bodybuilders at the gym - taking on tasks that seem Sisyphean to outsiders, for fun and to build their strength.
mholt
If you can't trust your network, you'll want encryption, regardless of devices on it.
geemus
We take security very seriously, which is why we designed Relay to work so that we never have to see your encryption keys. If Let's Encrypt is working well enough for you, that's great, but we've also heard about rough edges that people struggle with so we are trying to help them out.
aeaa3
Does this means that you have the ability to
a) impersonate the identities of your users and b) decrypt the SSL traffic of your users
?
benburkert
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
hannob
> 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.)
masfuerte
If users delegate their DNS to you, what's stopping you issuing a certificate to yourself for their site?
benburkert
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.
nbadg
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.
traceroute66
Oh dear.
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.
NoahZuniga
Your site doesn't work. The right arrow button is always disabled
benburkert
sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?
mano78
iOS safari
nodesocket
I'm a bit confused the benefits? Caddy already makes Let's encrypt incredibly easy. I use the CloudFlare DNS provider, so don't even need to expose port 80 for http verification.
bananapub
for everyone willing to put a tiny amount of effort in, you can just:
1. Install acme-dns somewhere
2. Point part of your domain to that
3. Use lego or caddy or whatever to get certs using dns-01
No need to pay some dude who can then forge certs for your domain.
From the cryptic terminal commands to the innumerable ways to shoot yourself in the foot, I always struggled to use TLS certificates. I love how much easier (and cheaper) Let's Encrypt made it to get certificates, but there are still plenty of things to struggle with.
That's why we built Relay: a free, browser-based tool that streamlines the ACME workflow, especially for tricky setups like homelabs. Relay acts as a secure intermediary between your ACME client and public certificate authorities like Let's Encrypt.
Some ways Relay provides a better experience:
Try Relay now: https://anchor.dev/relayOr read our blog post: https://anchor.dev/blog/lets-get-your-homelab-https-certifie...
Please give it a try (it only takes a couple minutes) and let me know what you think.