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:
- really fast, streamlined certificates in minutes, with any ACME client
- one-time upfront DNS delegation without inbound traffic or DNS credentials sprinkled everywhere
- clear insights into the whole ACME process and renewal reminders
Or 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.
I see organisations with thousands of SSL certificates, and their struggle is real. Even reputable companies with huge teams have their certificates expire or served badly. Some serve expired certificates for years!
Plus, enterprise alternatives are extremely costly and rigid.
* 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!
This would probably be easier if I was organized enough to use at least minimal MDM features on the family's devices though, so I haven't actually completed this project yet.
Ummmm why does my printer need a certificate?
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.
If they're persistently stealing traffic from my network then the printers administrative password is the least worrisome part.
> homelab enthusiasts are like bodybuilders at the gym
Self obsessed to the point of absurdity? There was a vulnerability a few years ago where you could embed an HP Printer Firmware update into the middle of a print file by taking advantage of some insane JCL commands. You can also embed JCL commands directly into a word document.
So these researchers created a word document that when printed updates your printers firmware with a hacked version allowing an advanced persistent threat to live inside your printer.
If your printer has no anti virus or no intrusion detection then putting an SSL certificate on there is entirely pointless.
...then (at least in theory!) there's no reason to not also give every one of those devices, with their public-routable IPv6 addresses, a stable public-rooted name — i.e. a DNS FQDN.
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.
A theoretical "DDNSv6", meanwhile, would instead expose your entire LAN as AAAA records under your DDNS suffix — much like how e.g. `tailscale share` exposes devices as device.yournetwork.ts.net. But using plain public-routed IPv6, rather than proprietary overlay routing.
The problem with this being that 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 to build AAAA records. But even then, some devices don't even do mDNS!)
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. (Why would it? It expects to only ever be local-segment routable, and for physical access to the network segment to be the sum total of its security mechanism.) To work around this, you'd need your gateway router to do L7 IPv6 routing (imagine if your router worked like Cloudflare DNS, where you could "orange cloud" your LAN devices) so that the router itself could 1. force itself as the default route for the device, even for LAN-to-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.
Is this because an ipv6 network doesn't have DHCP which has the side effect of telling the router the hostname of the machine asking for an IP?
one minor correction: modern (even 5-10 year old) printers do support TLS -- and they even try to push you to use it when they only have the built-in self-signed certificate. I've seen screens encouraging me to "click trust" etc. which seems idiotic to train anyone to do when the stakes of letting them admin the printer, over the LAN, over HTTP are so low. I'm so sure that a random rogue IOT device on my LAN is listening to that printer administration traffic, real high-value stuff there. Mind you that this is unrelated to whether a rogue LAN actor could sniff the actual documents being printed, since I don't think computers are typically set up to print with IPP over TLS, but use unencrypted protocols instead.
Anyway, with my HP printer, you can upload a cert and key file and that way it'll use a cert of your choice.
https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
Setup and forget is never good for security. From what I see with sslboard.com (I'm the founder), all hosts serving old expired certificates also have bad TLS versions and ciphers (RC4, DES) and vulnerabilities.
Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.
This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is needed.
I wrote much more here: https://alexsci.com/blog/is-email-confidential-in-transit-ye...
I honestly don't know if I fully buy that argument, but there's something to be said for the idea that the problem with "better than nothing" is that it presupposes "nothing" is what you'd otherwise end up with and the crummy solution is the best you're going to get. I think your blog post highlights this point. Encrypting email even without validating certificates is better than not doing the encryption at all, but is giving people the security blanket of "at least we're doing something" slowing down the process of taking that last step?
The browser limits on maximum certificate lifetimes only apply to the public web PKI, not to CAs that you configure yourself.
When creating your CA certificate you can hop into the Advanced tab and add the following line to constrain it to specific domains. This eliminates the risk of your likely-poorly-secured CA being abused to MITM all of your communications:
nameConstraints=critical,permitted;DNS:.home.internal
myawesomedomain.com {
respond "You just loaded this on https"
}
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
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.)
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.
If that were true, nobody would need signed certificates in the first place.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
https://crt.sh for point in time checks, https://sslboard.com for comprehensive oversight (disclosure: I'm the founder)
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.
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.
The point of acme-dns is for people who 1) need to use DNS validation because they don't have an externally accessible web server or need a wildcard cert and 2) either use DNS providers that don't provide API support or whose API support has not been integrated into their tool of choice like cert-manager or certbot.
I have had to use ACME-DNS for that reason, and I don't think it is a horrible business to try to offer that as a service. I don't think I would use it (since acme-dns isn't that hard to set up and I am familiar with it), but I could imagine other people might want to.
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.