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

51–60 of 68 posts

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

#51

Post by eo3x0 »

matahwoosh wrote: post #15
hw wrote: post #11

Clearalias.com is another service that provides SSL multi-tenant apps and SaaSes that want to provide secured custom domains for their customers. There's only one step required by the customer which is to point their DNS to Clearalias, no API calls or extra set up by the app or the customers.

Ohai! Yeah, you can do the same thing with Fly (which is what most of our customers do - just point DNS at Fly). I cannot stress enough how nice it is being able to build on top of Let's Encrypt! bows The API is mainly for people who'd like to automate the process, because they want to provide custom domains for their customers (so more for B2B use-cases) ;)

The grandparent post means that the customer hostnsmes also work without any API calls if configured properly.

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

#52

Post by vog »

thiagocsf wrote: post #50

It’s a x.509 certificate, not ssl. Also, the ssl protocol has been deprecated in favour of tls. I’ll let tls certificate slide but ssl certificate just triggers me too much.

What's the point of this nitpicking?

The title is perfectly fine for its purpose.

First, thanks to the terminology used by almost all commercial CAs, "SSL Certificates" is still the most commonly known term for that. Like it or not, but if you want to reach a wide audience, you need to say SSL in addition to TLS.

Second, even fewer people know the term X.509, insisting on that is like insisting on saying RFC-7540 instead of HTTP/2.

Third, in the very first sentence the article sets everything straight:

> We've been hard at work making Let's Encrypt TLS certificates as simple and safe as possible for developers and creators of all kinds

So ... is this an instance of commenting before actually having had just a tiny look at the article?

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

#53

Post by vog »

mschuster91 wrote: post #33
stevenwoo wrote: post #22

Earlier quoted context omitted.

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…

> 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).

Is this really more stable than a simple cronjob? It is far more complicated, for sure, so there should be significant benefits to make up for that.

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

#54

Post by parasubvert »

vog wrote: post #52
thiagocsf wrote: post #50

It’s a x.509 certificate, not ssl. Also, the ssl protocol has been deprecated in favour of tls. I’ll let tls certificate slide but ssl certificate just triggers me too much.

What's the point of this nitpicking? The title is perfectly fine for its purpose. First, thanks to the terminology used by almost all commercial CAs, "SSL Certificates" is still the most commonly known term for that. Like it or not, but if you want to reach a wide audience, you need to say SSL in addition to TLS. Second, even fewer people know the term X.509, insisting on that is like insisting on saying RFC-7540 ins…

Because it is important that everyone understand that SSL is dead and TLS is the replacement. SSL/TLS is forgivable, saying SSL is sort of like writing a headline “How this company uses VHS” when you actually meant Betamax. It’s misleading.

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

#55

Post by vog »

parasubvert wrote: post #54
vog wrote: post #52

Earlier quoted context omitted.

What's the point of this nitpicking? The title is perfectly fine for its purpose. First, thanks to the terminology used by almost all commercial CAs, "SSL Certificates" is still the most commonly known term for that. Like it or not, but if you want to reach a wide audience, you need to say SSL in addition to TLS. Second, even fewer people know the term X.509, insisting on that is like insisting on saying RFC-7540 ins…

Because it is important that everyone understand that SSL is dead and TLS is the replacement. SSL/TLS is forgivable, saying SSL is sort of like writing a headline “How this company uses VHS” when you actually meant Betamax. It’s misleading.

I still don't get it. This is clarified in the very first sentence of TFA. Why do you think it needs to be stuffed into the title?

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

#56

Post by mcny »

vog wrote: post #55
parasubvert wrote: post #54

Earlier quoted context omitted.

Because it is important that everyone understand that SSL is dead and TLS is the replacement. SSL/TLS is forgivable, saying SSL is sort of like writing a headline “How this company uses VHS” when you actually meant Betamax. It’s misleading.

I still don't get it. This is clarified in the very first sentence of TFA. Why do you think it needs to be stuffed into the title?

We wouldn't need to have this conversation if the title said TLS.

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

#57

Post by nailer »

mcny wrote: post #56
vog wrote: post #55

Earlier quoted context omitted.

I still don't get it. This is clarified in the very first sentence of TFA. Why do you think it needs to be stuffed into the title?

We wouldn't need to have this conversation if the title said TLS.

You're correct, but you're fighting an uphill battle: https://certsimple.com/blog/ssl-or-tls

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

#58

Post by [deleted] »

parasubvert wrote: post #54
vog wrote: post #52

Earlier quoted context omitted.

What's the point of this nitpicking? The title is perfectly fine for its purpose. First, thanks to the terminology used by almost all commercial CAs, "SSL Certificates" is still the most commonly known term for that. Like it or not, but if you want to reach a wide audience, you need to say SSL in addition to TLS. Second, even fewer people know the term X.509, insisting on that is like insisting on saying RFC-7540 ins…

Because it is important that everyone understand that SSL is dead and TLS is the replacement. SSL/TLS is forgivable, saying SSL is sort of like writing a headline “How this company uses VHS” when you actually meant Betamax. It’s misleading.

[deleted]

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

#59

Post by cagenut »

thaumaturgy wrote: post #3
tialaramex wrote: post #2

Would greatly benefit from explaining why they couldn't do dns-01 challenges successfully. This an issue all the way from individuals with crappy or misconfigured DNS locally to whole TLDs (fortunately no really major ones) with non-working DNS. But it's often a teachable moment, something others can learn from.

I'd like to see that too, especially since I've been doing fully-automated Let's Encrypt with dns verification for hosted domains for well over a year now. I might be able to offer a solution to whatever issue they've had.

would you consider writing up your system somewhere?

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

#60

Post by cm2187 »

mrkurt wrote: post #4
tialaramex wrote: post #2

Would greatly benefit from explaining why they couldn't do dns-01 challenges successfully. This an issue all the way from individuals with crappy or misconfigured DNS locally to whole TLDs (fortunately no really major ones) with non-working DNS. But it's often a teachable moment, something others can learn from.

DNS challenges weren't broken, they technically worked just fine. But they added an additional step to our setup process, and we were losing customers during signup because of it. We can still do the DNS challenge it's just not how we guide people through our setup. Basically with the DNS challenge, we had to send people away to make DNS changes, have them come back and confirm they were approved, and then we sent th…

Also my experience with DNS validation and let's encrypt is that propagation times can be variable. You do not know from where in the world the let's encrypt servers will contact your DNS, so you may see the new entries in your DNS, but it may not have been propagated yet to where let's encrypt query them. And then the validation failed and you need to start again from scratch. So you need to introduce some large delays to be safe.

Having DNS validation as an option is very useful, as not all certificates are used for http servers (think smtp) but not trivial to implement.

Also wildcard certs will require DNS validation.

Post reply on HN