14 ms·
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 r
by mattzito 10y ago
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-ssl-tls-for-all-squarespace-sites https://engineering.squarespace.com/blog/2016/implementing-s...
Saying it's "just" a 4x acme request annually demonstrates a real lack of understanding of supporting this kind of system at scale.
- Karunamon 10y agoI 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 10y agoThey 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 10y agoFoo! Okay, I thought they were doing LE certs for every dyno's name. One wildcard makes a lot more sense.
- packetized 10y agoFTA: 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.
- gergles 10y agoBut this is all engineering work that needs to be done for the system at all. None of these things have incremental costs that justify hiding encryption behind a paywall.