Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Deliver Global SSL with Let's Encrypt

fly.io

Post reply on HN
Print view View original

31–40 of 68 posts

Re: How We Deliver Global SSL with Let's Encrypt

#31

Post by zAy0LfpBZLC8mAC »

mrkurt wrote: post #27
zAy0LfpBZLC8mAC wrote: post #23

Earlier quoted context omitted.

And A and AAAA records are the only way to do HTTP with web browsers ... so?! What makes you think that CNAME or DNAME records are specific to A or AAAA records?!

I'm really struggling to understand what you're recommending. Will you explain how a DNAME works with the Lets Encrypt auth process in a way that makes it as simple as a single CNAME/a-record?

Well, you have them create a DNAME that maps theirhostname.theirdomain to yourhostidorsomething.yourdomain, and then you have in your nameserver A and AAAA records for yourhostidorsomething.yourdomain and a TXT record for _acme-challenge.yourhostidorsomething.yourdomain!?

(Obviously doesn't work if they are to keep control over other subdomains of theirhostname.theirdomain, and also, I haven't tried it with DNAMEs, so I don't know whether their implementation is buggy.)

Re: How We Deliver Global SSL with Let's Encrypt

#32

Post by zAy0LfpBZLC8mAC »

mrkurt wrote: post #28
zAy0LfpBZLC8mAC wrote: post #26

Earlier quoted context omitted.

Sorry, not trying to mock you, but I'm really curious how you (or anyone else on this thread who seems to be surprised by the possibility) managed to not know. I mean, assuming you do know that CNAMEs are a thing, this reads to me like "well, yes, HTTP can do redirects, but I didn't know you could also redirect requests for images!" ... I guess what I am wondering is: What is/was your mental model of CNAMEs that they…

I don't think we'd considered a CNAME to redirect the specific txt records that Lets Encrypt requires. It's not intuitively obvious that they support redirects for those lookups.

But how is it not?! I mean, apart from the fact that you never know whether software is buggy, of course.

CNAMEs are not a feature of application software, but rather a mandatory part of the DNS specification that any standards-compliant resolver has to implement. As they claim to be using DNS, that obviously implies the claim that they implement what the DNS specification defines, and that would necessarily include following CNAMEs.

Re: How We Deliver Global SSL with Let's Encrypt

#33

Post by mschuster91 »

stevenwoo wrote: post #22
k__ wrote: post #7

LE is awesome. Clients want an SSL server and it lets me set it up in 10 minutes without additional costs.

Yes this is a delight compared to the old way of having to hand over $10 or whatever to someone for a certificate that one had to remember to renew in a timely fashion versus just using a cron job now with LE.

Why use a cron job? I have certbot running in one Docker container, the .well-known route directing to the one dedicated Docker host running certbot, and whenever certbot renews the certificate, it writes the cert to the NAS share that is only mounted on the LBs and then triggers a SIGKILL to the haproxy docker containers (which causes haproxy to re-read the cert file and configuration).

Fully automated, no cronjobs to fail. In addition, I have a monitoring on all LBs that verifies the expiration time - it has never hit so far. That cronjob/monitoring is something everyone should have anyway because a well working monitoring system can alert you to so many other possible failure states...

Re: How We Deliver Global SSL with Let's Encrypt

#34

Post by infogulch »

zAy0LfpBZLC8mAC wrote: post #32
mrkurt wrote: post #28

Earlier quoted context omitted.

I don't think we'd considered a CNAME to redirect the specific txt records that Lets Encrypt requires. It's not intuitively obvious that they support redirects for those lookups.

But how is it not?! I mean, apart from the fact that you never know whether software is buggy, of course. CNAMEs are not a feature of application software, but rather a mandatory part of the DNS specification that any standards-compliant resolver has to implement. As they claim to be using DNS, that obviously implies the claim that they implement what the DNS specification defines, and that would necessarily include…

Part of it was that I'm not very familiar with the internals of the challenges and I didn't know that `_acme-challenge` was the record name for the dns-01 challenge. (I probably could have put 2+2 together if I realized this much.)

Another part was that I've never read the dns rfc and honestly I've only ever spent enough time messing with dns until it worked. And I've never seen a CNAME for a record that's resolves to anything but A (or AAAA or another CNAME). So I suppose it was a combination of a failure of imagination, lack of knowledge, and lack of experience. Or maybe, "I dunno I never thought about it".

But now I know! CNAMEs work for all records regardless of type, forwarding the entire lookup elsewhere, which I guess is why they require no other records exist with that name. Pretty cool.

I suppose I could have learned that with a bit less incredulity but hey, it got me here in the end. I guess a link to the RFC might be relevant here [CNAME 1]. I'll probably look through it later, maybe there's some other cool features I didn't know about.

[1]: https://tools.ietf.org/html/rfc1034

Re: How We Deliver Global SSL with Let's Encrypt

#35

Post by nodesocket »

Sorry a little off topic, but any idea when Let's Encrypt will (if ever) support wildcard SSL certs? We provision (https://commando.io) a subdomain for each of our accounts (thus thousands of subdomains) using a wildcard DNS A record. Willing to pay, as long as it is less than the $99 a year currently paying through NameCheap.

Re: How We Deliver Global SSL with Let's Encrypt

#36

Post by matahwoosh »

nodesocket wrote: post #35

Sorry a little off topic, but any idea when Let's Encrypt will (if ever) support wildcard SSL certs? We provision ( https://commando.io ) a subdomain for each of our accounts (thus thousands of subdomains) using a wildcard DNS A record. Willing to pay, as long as it is less than the $99 a year currently paying through NameCheap.

LE still says Jan '18 - https://letsencrypt.org/upcoming-features/

Re: How We Deliver Global SSL with Let's Encrypt

#37

Post by matahwoosh »

matahwoosh wrote: post #36
nodesocket wrote: post #35

Sorry a little off topic, but any idea when Let's Encrypt will (if ever) support wildcard SSL certs? We provision ( https://commando.io ) a subdomain for each of our accounts (thus thousands of subdomains) using a wildcard DNS A record. Willing to pay, as long as it is less than the $99 a year currently paying through NameCheap.

LE still says Jan '18 - https://letsencrypt.org/upcoming-features/

for the time being, you could try to issue SAN certs with LE (from their website):

"If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week."

Re: How We Deliver Global SSL with Let's Encrypt

#38

Post by [deleted] »

matahwoosh wrote: post #37
matahwoosh wrote: post #36

Earlier quoted context omitted.

LE still says Jan '18 - https://letsencrypt.org/upcoming-features/

for the time being, you could try to issue SAN certs with LE (from their website): "If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week."

[deleted]

Re: How We Deliver Global SSL with Let's Encrypt

#39

Post by mrkurt »

nodesocket wrote: post #35

Sorry a little off topic, but any idea when Let's Encrypt will (if ever) support wildcard SSL certs? We provision ( https://commando.io ) a subdomain for each of our accounts (thus thousands of subdomains) using a wildcard DNS A record. Willing to pay, as long as it is less than the $99 a year currently paying through NameCheap.

We can handle wildcards now, we just issue new certs when we see new subdomains (we have a 2500/wk rate limit from LE and will implement SANs if you need them). Feel free to email I'd you want to set it up. :)

Re: How We Deliver Global SSL with Let's Encrypt

#40

Post by mrkurt »

prdonahue wrote: post #30
geetfun wrote: post #8

Interesting product - fly.io It’s essentially a reverse proxy as a service. Sort of like Cloudflare but with what looks like a nicer API, and custom domain name SSL eg. for multi tenant apps. It was a bit pricy when I plugged in how many requests we get per month on our servers, easily in 5-figure per month. Having said that, internally we built most of their selling points already.

Our API for doing this is quite simple: POST https://api.cloudflare.com/client/v4/zones/:zone_id/custom_hostnames { "hostname":"app.example.com", "ssl": { "method":"http", "type":"dv" } } In addition to "http" (described in this thread) we also support "cname" and "email" methods for validation. Some of our customers prefer these other methods as it lets us issue the certificates before /their/ customer points the CN…

You didn't mention price. :)
Post reply on HN