21–30 of 43 posts
Why would you pin a certificate that you did not generate for a domain that's not yours?
Some people despite the warnings and consequences can't help themselves :)
Heroku also doesn't enforce any verification that you own a domain name. Another user can simply add any domain they like to their app if you haven't claimed it by adding it to your app first. Regardless of ownership and you will no longer be able to add your own domain to your app getting a generic "domain is already in use" error. Happened to me a few years ago, had to reach out to support and prove I owned the dom…
How does GitHub’s gh pages handle this? I don’t remember them doing anything either.
So far GitLab seems to be the best one I've run into, they do validation, and as long as you keep control of the domain, you keep control of your pages.
Wow. I really hope they’ll get it done before the expiration date but I always thought they’d be renewing months in advance at minimum. Are they trying to negotiate something?
Heroku replaced their wildcard certificate in plenty of time but many customers do not anticipate anything changing ever and will fiercely resist this simple fact, so for those customers stuff blew up.
Remember the Y2K problem is the result of software written not in 1901 or even just 1981 but even well into the 1990s with the calm certainty that all years begin 19xx.
Heroku can try brown out policies, but this sort of customer intransigence is very difficult to defeat. The customer is quite certain they're right, who ever heard of "change" anyway? Everyone knows that the world is a flat plane, fixed in space, eternal and unchanging, this pinning rule I wrote in 2019 worked then, therefore it is still correct now.
Something that's nice about Let's Encrypt is that it forces you to change something every few months. After the first couple months, you'll probably get your issues worked out. If you just change certs every few years, then every few years you have some sort of disaster because of the "well we fixed it, we don't have to worry for two years" effect. A broader lesson is the importance of "trying out" rare events, even…
* Soon (although when exactly I'm not sure because it has been delayed at least once) the Let's Encrypt systems will tell compliant ACME clients that the "correct" intermediate is Let's Encrypt's ISRG-signed X3 intermediate. This is a different certificate for the same X3 private key you're used to but not signed by the same trust root. If you use a correct client and have done things properly, this may cut off TLS clients for your systems that don't trust ISRG (the charity which runs Let's Encrypt). Six year old Android phones, the Windows XP system you know should have been retired, a VoIP desk phone running out-of-date firmware, stuff like that.
* In March 2021 the X3 Intermediate expires. If your certificate software was not compliant with ACME, or you manually overrode it to use the old certificates to avoid the problem in the previous item, things break now. More things, and worse. Although...
* Maybe before March 2021 the Let's Encrypt systems stop issuing from those soon-to-be-obsolete Intermediates and use newer ones instead perhaps named Y3 and Y4. In this case if you've jury rigged things (in an ACME non-compliant way) to keep using the old X3 intermediate that'll break suddenly after your renewal. Common web browsers may not trust the nonsense you're emitting, exactly which browsers break may vary depending on exactly what stupid things you did, but chances are you haven't tested and don't know. If you are using a compliant client then modern browsers are all fine, but archaic stuff breaks suddenly.
* In September 2021 the DST Root X3 root expires. If you have somehow clung on to trust via this root, whether through your own effort or via trust path discovery code inside client systems, that goes away instantly. Any systems that don't trust ISRG will refuse to trust your certificates, no matter how often you re-issue them and reconfigure things, those clients themselves need updating urgently and you probably have no way to do that. Oops.
Why would you pin a certificate that you did not generate for a domain that's not yours?
Once upon a time a UK model train manufacturer had a warning inside the box of your new loco or rolling stock that said something like "Do not dismantle out of idle curiosity". Some people despite the warnings and consequences can't help themselves :)
1) people are dismantling goods, then ringing for advice but being embarrassed they broke it, then rebuying when we refuse advice,
2) tell people not to dismantle it, they'll get curious and do the opposite,
3) ...
4) pro-fit!
Something that's nice about Let's Encrypt is that it forces you to change something every few months. After the first couple months, you'll probably get your issues worked out. If you just change certs every few years, then every few years you have some sort of disaster because of the "well we fixed it, we don't have to worry for two years" effect. A broader lesson is the importance of "trying out" rare events, even…
Although, speaking of Let's Encrypt, there will be a series of disruptive events over the next 18 months or so. * Soon (although when exactly I'm not sure because it has been delayed at least once) the Let's Encrypt systems will tell compliant ACME clients that the "correct" intermediate is Let's Encrypt's ISRG-signed X3 intermediate. This is a different certificate for the same X3 private key you're used to but not…
Something that's nice about Let's Encrypt is that it forces you to change something every few months. After the first couple months, you'll probably get your issues worked out. If you just change certs every few years, then every few years you have some sort of disaster because of the "well we fixed it, we don't have to worry for two years" effect. A broader lesson is the importance of "trying out" rare events, even…
I have a homebrew Internet-of-shit device that I know has LE hardcoded. I'll have to take it of the wall and reflash if I switch to a new CA (or potentially when some of the changes described by tialaramex happen - I think I hardcoded the new root but I'm not 100% sure).
It already broke a few days ago: https://status.heroku.com/incidents/2045
Yep, we were down during that time. I don't know what Heroku is doing with this certificate thing, but seems like a mess.
Why would you pin a certificate that you did not generate for a domain that's not yours?
This usually happens beacuse some applications don't use by default the root CA bundle of the underlying OS to authenticate TLS connections, but require you to put each Root CA certificate in a trust store (ex. Java).
Some devs probably added just the Digicert root CA and forgot about it.
These kind of changes with certificate are always kind of tricky, because they usually work very reliably until they don't.
Something that's nice about Let's Encrypt is that it forces you to change something every few months. After the first couple months, you'll probably get your issues worked out. If you just change certs every few years, then every few years you have some sort of disaster because of the "well we fixed it, we don't have to worry for two years" effect. A broader lesson is the importance of "trying out" rare events, even…
The downside is that due to a lack of serious competition, Let's Encrypt seems like an obvious choice, and thus it can be tempting to hardcode it. I have a homebrew Internet-of-shit device that I know has LE hardcoded. I'll have to take it of the wall and reflash if I switch to a new CA (or potentially when some of the changes described by tialaramex happen - I think I hardcoded the new root but I'm not 100% sure).
Let’s encrypt only real hold is their root certificate is now in many trust stores , if you control both sides self signed certificates are perfectly fine you don’t need a CA at all