6 ms·

Show HN: Anchor Relay – A faster, easier way to get Let's Encrypt certificates

80 points by geemus 1y ago

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: - 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 Try Relay now: https://anchor.dev/relay https://anchor.dev/relay Or read our blog post: https://anchor.dev/blog/lets-get-your-homelab-https-certified 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.

xmprt 1y ago
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.
- geemus 1y ago
  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.
- michaelt 1y ago
  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!
  - eternauta3k 1y ago
    Why not sign it yourself?
    - woodruffw 1y ago
      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]. [1]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
      - xp84 1y ago
        I started but haven't yet completed a project to use mkcert on a home server, and get all devices in the house to trust it as a CA for things such as printers and "internal tools" for my family such as Jellyfin, etc. 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.
  - toast0 1y ago
    > * If you want an SSL certificate for, say, your printer Ummmm why does my printer need a certificate?
    - mholt 1y ago
      If you can't trust your network, you'll want encryption, regardless of devices on it.
      - Palomides 1y ago
        if you can't trust your network, everything needs to be public internet level hardened anyway, so why not just directly use letsencrypt?
        1y ago
- weddpros 1y ago
  There's a scale beyond which the real challenge isn't issuing a certificate. 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.
  - tenuousemphasis 1y ago
    All the more reason to automate renewing of certificates.
    - weddpros 1y ago
      Sure! yet automation only solves one problem (until it doesn't). Inventory and control/accountability is still needed at scale, and automation doesn't provide it.
NoahZuniga 1y ago
Your site doesn't work. The right arrow button is always disabled
- benburkert 1y ago
  sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?
  - mano78 1y ago
    iOS safari
aeaa3 1y ago
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 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 works in our docs: https://anchor.dev/docs/public-certs/acme-relay https://anchor.dev/docs/public-certs/acme-relay
  - masfuerte 1y ago
    If users delegate their DNS to you, what's stopping you issuing a certificate to yourself for their site?
    - nbadg 1y ago
      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.
      - weddpros 1y ago
        Seeing how people are worried about third parties issuing certificates, I encourage using a tool to monitor CT Logs. It really makes the fog of war disappear around your certificates. https://crt.sh https://crt.sh for point in time checks, https://sslboard.com https://sslboard.com for comprehensive oversight (disclosure: I'm the founder)
    - 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/ 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.
traceroute66 1y ago
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. [1] https://letsencrypt.org/docs/client-options/ https://letsencrypt.org/docs/client-options/
- cortesoft 1y ago
  I haven't fully looked into it, but it seems to me that this is basically a hosted version of Acme-dns (https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns) 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.
- 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 it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.
nodesocket 1y ago
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.
- cortesoft 1y ago
  I am pretty sure the main purpose is for people who use a DNS provider that does not have integrated support with certbot or cert-manager (basically this is a hosted acme dns (https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns)
bananapub 1y ago
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.
- cortesoft 1y ago
  Every single SAAS product faces this criticism. You can always do it yourself, but if some people don't want to, I don't think it is bad to offer a hosted version.
deleted 1y ago
[deleted]
bobbob1921 1y ago
I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext, yet plaintext has to get used because of some element of certificates expiring needs renwal. Even bad or easy to crack encryption is better than plain text, yet I totally get why many scenarios end up using plain text (i’m talking in an internal or home lab type set up). I understand why public facing certificates need renewals
- cortesoft 1y ago
  > I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.
  - 8organicbits 1y ago
    Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate. 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-yet/ https://alexsci.com/blog/is-email-confidential-in-transit-ye...
    - rainsford 1y ago
      I definitely agree it's strictly better than plaintext. But the counter argument is that introducing bad encryption makes it less likely you'll ever end up with good encryption because the perceived delta between good and bad encryption isn't enough to make people invest the effort compared to fixing the more obviously bad situation of just plaintext. 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?
codegeek 1y ago
Or just use caddy as a reverse proxy [0]. This 1 line will do it all for you: myawesomedomain.com { respond "You just loaded this on https" } [0] https://caddyserver.com https://caddyserver.com
- Cockbrand 1y ago
  I only recently got into Caddy after using Apache and later Nginx for decades, and it's almost disappointing how little configuration it needs. It's very refreshing that we finally have a web server that needs hardly any fiddling with b/c it has nicely sane and comprehensive defaults.
  - codegeek 1y ago
    Once you go Caddy, you never go back to Nginx and Apache.
- princevegeta89 1y ago
  +1 to Caddy - Another happy user that stopped caring about managing SSL certs 3 years ago.
8organicbits 1y ago
EFF has a great write up of the 'validation domain CNAME' approach this uses. It's great to see another entry in this space. As great as ACME is, there are still sharp edges we can improve with tricks like this. https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
skyzouwdev 1y ago
[dead]
natewww 1y ago
cool idea

80 points by geemus 1y ago

xmprt 1y ago

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.

geemus 1y ago
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.
michaelt 1y ago
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!
- eternauta3k 1y ago
  Why not sign it yourself?
  - woodruffw 1y ago
    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]. [1]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
    - xp84 1y ago
      I started but haven't yet completed a project to use mkcert on a home server, and get all devices in the house to trust it as a CA for things such as printers and "internal tools" for my family such as Jellyfin, etc. 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.
- toast0 1y ago
  > * If you want an SSL certificate for, say, your printer Ummmm why does my printer need a certificate?
  - mholt 1y ago
    If you can't trust your network, you'll want encryption, regardless of devices on it.
    - Palomides 1y ago
      if you can't trust your network, everything needs to be public internet level hardened anyway, so why not just directly use letsencrypt?
      - 1y ago
weddpros 1y ago
There's a scale beyond which the real challenge isn't issuing a certificate. 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.
- tenuousemphasis 1y ago
  All the more reason to automate renewing of certificates.
  - weddpros 1y ago
    Sure! yet automation only solves one problem (until it doesn't). Inventory and control/accountability is still needed at scale, and automation doesn't provide it.

NoahZuniga 1y ago

Your site doesn't work. The right arrow button is always disabled

benburkert 1y ago
sorry about that! mind sharing what domain name (or something similar that also doesn't work) & what browser you used?
- mano78 1y ago
  iOS safari

aeaa3 1y ago

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 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 works in our docs: https://anchor.dev/docs/public-certs/acme-relay https://anchor.dev/docs/public-certs/acme-relay
- masfuerte 1y ago
  If users delegate their DNS to you, what's stopping you issuing a certificate to yourself for their site?
  - nbadg 1y ago
    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.
    - weddpros 1y ago
      Seeing how people are worried about third parties issuing certificates, I encourage using a tool to monitor CT Logs. It really makes the fog of war disappear around your certificates. https://crt.sh https://crt.sh for point in time checks, https://sslboard.com https://sslboard.com for comprehensive oversight (disclosure: I'm the founder)
  - 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/ 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.

traceroute66 1y ago

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. [1] https://letsencrypt.org/docs/client-options/ https://letsencrypt.org/docs/client-options/

cortesoft 1y ago
I haven't fully looked into it, but it seems to me that this is basically a hosted version of Acme-dns (https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns) 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.
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 it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.

nodesocket 1y ago

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.

cortesoft 1y ago
I am pretty sure the main purpose is for people who use a DNS provider that does not have integrated support with certbot or cert-manager (basically this is a hosted acme dns (https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns)

bananapub 1y ago

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.

cortesoft 1y ago
Every single SAAS product faces this criticism. You can always do it yourself, but if some people don't want to, I don't think it is bad to offer a hosted version.

deleted 1y ago

[deleted]

bobbob1921 1y ago

I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext, yet plaintext has to get used because of some element of certificates expiring needs renwal. Even bad or easy to crack encryption is better than plain text, yet I totally get why many scenarios end up using plain text (i’m talking in an internal or home lab type set up). I understand why public facing certificates need renewals

cortesoft 1y ago
> I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.
- 8organicbits 1y ago
  Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate. 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-yet/ https://alexsci.com/blog/is-email-confidential-in-transit-ye...
  - rainsford 1y ago
    I definitely agree it's strictly better than plaintext. But the counter argument is that introducing bad encryption makes it less likely you'll ever end up with good encryption because the perceived delta between good and bad encryption isn't enough to make people invest the effort compared to fixing the more obviously bad situation of just plaintext. 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?

codegeek 1y ago

Or just use caddy as a reverse proxy [0]. This 1 line will do it all for you: myawesomedomain.com { respond "You just loaded this on https" } [0] https://caddyserver.com https://caddyserver.com

Cockbrand 1y ago
I only recently got into Caddy after using Apache and later Nginx for decades, and it's almost disappointing how little configuration it needs. It's very refreshing that we finally have a web server that needs hardly any fiddling with b/c it has nicely sane and comprehensive defaults.
- codegeek 1y ago
  Once you go Caddy, you never go back to Nginx and Apache.
princevegeta89 1y ago
+1 to Caddy - Another happy user that stopped caring about managing SSL certs 3 years ago.

8organicbits 1y ago

EFF has a great write up of the 'validation domain CNAME' approach this uses. It's great to see another entry in this space. As great as ACME is, there are still sharp edges we can improve with tricks like this. https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

skyzouwdev 1y ago

[dead]

natewww 1y ago

cool idea