
Announcing Free and Automated SSL Certs - adelcambre
https://blog.heroku.com/announcing-automated-certificate-management
======
Clex
This is great news, thanks Heroku. This feature sticks well to their "code, we
do the rest" philosophy.

I hope the other PaaS will follow.

~~~
yannski
Scalingo has it for a few months
[https://blog.scalingo.com/2016/12/24/letsencrypt.html](https://blog.scalingo.com/2016/12/24/letsencrypt.html)

------
homerguy69
Sweet, this is basically want Lets Encrypt wanted, make the market go towards
this free SSL model.

~~~
Nadya
Companies who aren't in the business of selling TLS [0] certs themselves have
little excuse to _not_ offer free TLS via Let's Encrypt. It's an advantage
over any competitors who haven't set that process up.

If your company does hosting - your company should provide TLS certs via Let's
Encrypt _automatically_.

[0] Can we start dropping the SSL part now? Generally SSL v2/v3 is disabled so
it is all over TLS anyway.

~~~
user5994461
> If your company does hosting - your company should provide TLS certs via
> Let's Encrypt automatically.

Correction: As part of the paid plan.

Why give for free sometimes you can charge money for.

~~~
JoshTriplett
If you have a free plan at all, then the only reason TLS should not be a paid
feature would be if you intentionally want to position the free plan as "don't
take this seriously because you can't build anything production-quality on
it".

~~~
user5994461
That makes sense for a hosting service. A lot of them works that way. Hosting
a static free blog doesn't need TLS.

~~~
icebraining
Considering the amount of crap ISPs have been known to inject into websites, I
disagree. TLS isn't just for encryption, it also provides data integrity.

~~~
Godel_unicode
This is the correct answer. Use this reasoning.

------
splatcollision
Etsy's blog post is a great primer (as usual) on how to accomplish this kind
of thing: [https://codeascraft.com/2017/01/31/how-etsy-manages-https-
an...](https://codeascraft.com/2017/01/31/how-etsy-manages-https-and-ssl-
certificates-for-custom-domains-on-pattern/)

------
polysaturate
For anyone on the fence about using Heroku, this is a great value to those who
know how to deal with certs but wouldn't mind them automated and free for the
rest of the premium at Heroku.

------
agd
This is fantastic and will make setting up custom domains with SSL so much
easier!

------
mark_l_watson
Awesome. With the Hobby Dyno pricing and no effort support for Let's Encrypt,
Heroku is really hitting a sweet spot for supporting low volume web apps
(e.g., less that a 1000 daily visitors).

------
brightball
Great news! I was honestly wondering what was taking them so long on this one.
Seemed like a no brainer.

------
BrandoElFollito
I believe the title is missing "for all paid dynos"

Which somehow changes its meaning .

------
Elect2
Does it support wildcard?

~~~
jldugger
Does it need wildcard?

~~~
jldugger
It's a serious question, if you have unlimited and automated SSL certificates,
what is the purpose of wildcards?

~~~
drchickensalad
Dynamic subdomains

~~~
jldugger
Does Heroku support that?

~~~
dbbk
Of course.

------
spacehunt
Private Spaces not supported :(

------
solidr53
Great news! So are we any closer to HTTP/2 on heroku?

~~~
nailer
Also Heroku don't support ECDSA (stronger / faster than RSA) yet.

------
Animats
_" free for all paid Dynos on Heroku’s Common Runtime."_

Not free. Included with purchase.

~~~
always_good
Well, the context is that you used to have to pay for it, and now you don't.

That's the announcement.

------
Karunamon
Free SSL.. for all paid dynos. Apparently, if you're developing an
application, you are expected to be okay with having your stuff MITMed.

Yes, this is me being excessively negative. Not having SSL-by-default in 2017
is excessively stupid. The certs are free, the system fully automated from
both sides. Why hold back?

 _There is no excuse for not having it system wide._ Unencrypted HTTP needs to
start being treated as the danger it is.

~~~
michaelper22
Free dynos with a ____.herokuapp.com domain have SSL enabled by default, at no
cost (under their wildcard certificate?). Seems the only missing case is when
using a custom domain with a free dyno.

~~~
Karunamon
It's an _obvious_ missing case, and one that they are clearly conscious of
given the constant insertion of the word "paid" in front of "dyno" throughout
this announcement post.

The mentality of holding out SSL as a paid addon needs to end. It needed to
end years ago. It had no excuse to not end the moment LetsEncrypt went live.

~~~
mattzito
Implementing support for LetsEncrypt SSL does have a cost associated with it,
particularly at scale. I think restricting the feature to paid users is
totally reasonable, particularly since it's still vastly cheaper than getting
a traditional SSL certificate.

~~~
Karunamon
And what exactly would that cost be? Can it even be quantified?

We're speaking of a 4x yearly ACME request of a few kilobytes going to and
from the LE servers. It certainly isn't bandwidth.

The engineering work was already done, and doesn't change based on the number
of instances that are making the cert request. It certainly isn't labor.

It certainly isn't storage. Certs are 2-4 kilobytes. Even if we assume Heroku
has 5M active dynos and each one has its own unique cert, that's only 20
gigabytes worth of certs, which is miniscule.

So where's the cost coming from? Answer: It isn't. This is just tier
differentiation, not cost recovery.

~~~
mattzito
Oh my - so, it's actually a lot more complicated than that. Let me run it
through for you:

\- You have to build enough of a retry algorithm so that you start renewing
well in advance of the expiration date.

\- You then have to build the mechanism for warning customers that there was
an issue renewing for one of a variety of reasons

\- You then have to deal with situations where LE has issues, which happens
fairly often

\- There's a queueing system, where you have to handle not sending too many
certs at once

\- You will end up in scenarios where users will migrate off of you, not tell
you, attempt to issue another LE cert with another service, and fail, and then
blame you

\- Similarly, you will have users who connect and disconnect domains, and your
system has to be smart enough to properly revoke certificates without locking
out a domain from too many retries

\- and then what happens when you can't renew a cert for whatever reason? Do
you break the user's site? Do you fall back to http?

I'm not saying it's millions of dollars, but at scale, it's complicated.
Here's a blog post about how Squarespace did this (disclosure, I work there):

[https://engineering.squarespace.com/blog/2016/implementing-s...](https://engineering.squarespace.com/blog/2016/implementing-
ssl-tls-for-all-squarespace-sites)

Saying it's "just" a 4x acme request annually demonstrates a real lack of
understanding of supporting this kind of system at scale.

~~~
Karunamon
I didn't say that it was easy. I enumerated three things that it can't be.

Given that Heroku is already generating certs on the fly for the (randomly
named) dynos, offering _that_ is _even more_ engineering work than just
sending a cert request for a custom domain, the numbers of which will be
significantly smaller. _[DISREGARD THIS - no they 're not. Those are all on a
single wildcard]_

My whole gist here is that every conceivable practical excuse I can think of
for not extending that feature out to custom domains resolves as a nonissue,
which only leaves feature differentiation to drive sales as the remaining
option.

Which, as mentioned before, is a legitimate business tactic, but morally
_evil_ in the security climate of 201x+.

~~~
packetized
They aren't generating certs on the fly for randomly named dynos:

    
    
      -bash-4.1$ curl -vkLs https://wind-river-5693.herokuapp.com 2>&1 | grep certificate
      * Server certificate: *.herokuapp.com
      * Server certificate: DigiCert SHA2 High Assurance Server CA
      * Server certificate: DigiCert High Assurance EV Root CA
      -bash-4.1$

~~~
Karunamon
Foo! Okay, I thought they were doing LE certs for every dyno's name. One
wildcard makes a lot more sense.

~~~
packetized
FTA:

    
    
      ACM handles all aspects of SSL/TLS certificates for _custom domains_;
      you no longer have to purchase certificates, or worry about their
      expiration or renewal.
    

Emphasis mine.

