18 ms·
Let’s Encrypt to transition to ISRG root
- nimbius 7y agoISRG stands for Internet Security Research Group.
- sihoang 7y agoThis is in their latest blog post "Christine expands our board’s global perspective with her career experience. She worked for many years in the Australian government" I was wondering what impact if she, a board member of ISRG, has to comply with the Australian encryption laws?
- SXX 7y agoCA have zero control over your encryption keys as is. As for the MitM there likely several CAs actually based and doing business in Australia. Yet with certificate transparency being mandatory it's almost guaranteed that entity doing something shady will go out of business really fast.
- tssva 7y agoNot that I actually would be at all, but hypothetical I would be more concerned with them hiring an Australian engineer than adding an Australian board member. What is the board member going to do to compromise operational security?
- arminiusreturns 7y agoInfluence hiring to get the engineer spy in. Also CIA docs have been published that said they had a system where people would purposefully tie down a company by being inefficient and causing beaucratic messeshttps://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf https://www.cia.gov/news-information/featured-story-archive/...
- jaas 7y agoAnd ISRG is the non-profit legal entity behind Let's Encrypt: https://www.abetterinternet.org/ https://www.abetterinternet.org/
- lucaspottersky 7y agothanks! i was amazed how this information is buried and how they assume everyone should know what ISRG means.
- viraptor 7y agoThey haven't really published a list of good/bad clients. I'm interested in what's the practical cutoff point with mobile phones? I expect desktop browsers will be less of an issue.
- p4bl0 7y agoThey provide a test site. It works on my Android One: https://valid-isrgrootx1.letsencrypt.org/ https://valid-isrgrootx1.letsencrypt.org/ People with other versions of Android and iOS can test and report here?
- gpvos 7y agoThat site should have some text on it like "If you did not get any errors or warnings while opening this web page, your computer or device knows about the ISRG root certificate and Let's Encrypt will continue to work for you." Currently, this isn't immediately clear to (relative) laypeople like me.
- tialaramex 7y agoThat test site, though they do link it in their own announcement was actually created as part of their compliance with root trust programme conditions. Specifically Mozilla's conditions require them to prove their setup actually works (modulo the trust they're requesting) by setting up a web site with certificates that would work once that trust is granted. They were also required to provide example sites with e.g. expired certs so that a Firefox developer could check that does what you'd expect. The good news is that unlike some of the required test sites, which took a bunch of advanced planning (you can't ask Let's Encrypt's service to mint you an expired cert so the expired cert was produced by requesting a valid cert and then waiting for it to expire and making sure not to lose it...) this test is easy for anybody knowledgeable to manually reproduce in a few minutes, as it's just the "wrong" certificate chain with the good trusted leaf certificate you got from Let's Encrypt. So even if they don't heed your call I'm sure someone else can.
- Fradow 7y ago
- founderling 7y agoIs it still hard to do wildcard certs with them? That is one of the reasons I don't use let's encrypt.
- throwaway5d097 7y agoIt's easier now with ACME v2 and using DNS for authentication or whatever.
- p4bl0 7y agoI can confirm, I recently did it using certbot and it was an easy and smooth process.
- josteink 7y agoIt’s easy if you have a DNS provider for which there is a DNS-auth module. This was one of the reasons for me switching to Cloudflare DNS, although many other providers should work too.
- xref 7y agoUnfortunately CloudFlare doesn’t provide limited-scope API keys so every server requesting certs needs your global API key which is the keys-to-the-kingdom...so be careful.
- josteink 7y agoI actually have the reverse model: requesting certs is done by its own isolated and dedicated container and scp’d to the server which needs it. Compromising a web-server will thus not compromise my DNS.
- xref 7y agoI like the sound of this idea, happen to have a Dockerfile/scripts for it on GitHub?
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- rocqua 7y agoI'm not an expert of certificates, but some quick skimming of https://tools.ietf.org/html/rfc5280#section-4.1 https://tools.ietf.org/html/rfc5280#section-4.1 suggests that a certificate only references the issuer certificate by name. Since, according to the article, the two different Lets encrypt intermediates have the same key, and the same name, they are interchangeable? As in, could I just replace the intermediate in my cert-chain and have everything continue smoothly? The end of the article suggests that this can't happen, but I can't quickly find what would stop this from happening.
- SifJar 7y ago> If you get a new certificate issued from the X3 intermediate that chains to the ISRG root, but you serve the old, cross-signed X3 intermediate in the TLS handshake, the connection will still work (* for now, keep reading). Seems to suggest "yes"
- theandrewbailey 7y agoYes, they are interchangeable. On my blog ( https://theandrewbailey.com/ https://theandrewbailey.com/ ), I have a "health check" page that includes all available trust chains. For my Let's Encrypt certificate, it shows 2: one through an intermediate to the DST Root, and another intermediate to the ISRG Root. I can verify that both exist and are used (though one certificate and intermediate are loaded and served): the current Firefox release (and all other browsers I've tried) uses the DST root, but Firefox Developer Edition uses the ISRG root. It seems to make sense: certificates don't sign certificates, keys sign certificates (more specifically, certificate requests). I don't see an obvious reason that a single certificate request can't be signed more than once. If one is, trust should flow through either certificate, since the certificate says that the signer verified that the holder has the associated private key, and if that private key signed another certificate, it should not matter which intermediate the trust goes through, so long as the root on the other end is trusted.
- rocqua 7y agoThanks! I can't seem to find the direct 'health-check' page though. Also, according to the spec, certificates sign a 'tbsCertificate' which contains all data of a certificate except for the actual signature and the field that determines what signing algorithm was used.
- michaelt 7y agoSo what motivates one CA to cross-sign another? I would have thought, if you were a CA you'd prefer not to enable your competitors - especially one who's planning to give away the product for free.
- Ayesh 7y agoCA market was so competitive, and with a free and open CAs coming in the future, IdenTrust probably grabbed the opportunity. It would be someone else if it wasn't IdenTrust. IdenTrust has OV, EV, managed PKI, and even DV certificates with 2 year validity that some legacy organization infrastructure requires.
- jlgaddis 7y agoThe greatest motivator of all, money!
- michaelt 7y agoHow much money are we talking here? Because most businesses, if you ask them "How much $$$ to destroy your business?" will respond "absolutely loads"
- londons_explore 7y agoThere are already many CA's, so the real answer is 'loads, but less if we think you'll just ask a competitor'.
- zAy0LfpBZLC8mAC 7y agoBut that wasn't the question. The question was "How much money do you want from us before we destroy your business?" For one, there are so many CAs that could potentially cross-sign, it's unlikely none will "defect" and take the opportunity to earn some money, but also, if none had cross-signed, they simply would have started later with their own root-cert, destroying the business anyway, so that's another reason to earn some money while you can.
- tialaramex 7y ago
- ilaksh 7y agoHow exactly would I set up my files or nginx config to use the old root?
- tialaramex 7y agoYou don't need to "use" the old root, you want to configure the chain of certificates provided so that it links back from your leaf cert to Identrust's "DST Root CA X3" not "ISRG Root X1". Specifically the chain will be just one cert, an "intermediate" which you want to ensure is the one cross-signed not the new one. This provides a hint to the client that it should trust this certificate because it can follow the trust back down the chain to DST Root CA X3 (which it trusts) not to ISRG Root X1 which is too new-fangled for it to have heard of. This page has both flavours of intermediate: https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ You want the one labelled: Let’s Encrypt Authority X3 (IdenTrust cross-signed) In nginx you need to concatenate the leaf certificate from Let's Encrypt (often a file named "cert.pem") with the file you downloaded from that site, to produce a chain, which you could call mychain.pem, and then tell nginx that's your certificate chain with a config line like: ssl_certificate /some/path/to/mychain.pem where right now you may see ssl_certificate /where/letsencrypt/puts/fullchain.pem
- AnssiH 7y agoInteresting that the referenced Let's Encrypt post from 2018 (https://letsencrypt.org/2018/08/06/trusted-by-all-major-root-programs.html https://letsencrypt.org/2018/08/06/trusted-by-all-major-root...) said "Some will not, and we’ll need to wait for the vast majority of those to cycle out of the Web ecosystem. We expect this will take at least five more years, so we plan to use a cross signature until then." So half a year ago they expected to continue cross-signing for 5+ years. What changed?
- Ajedi32 7y agoFor what it's worth, you'll still be able to use the old roots for another two and a half years (until September 29, 2021), which is not quite five years from the date of that old post, but also way longer than half a year.
- AnssiH 7y agoI wonder what Google will do with their Cloud Platform Google-managed SSL certificates that have used Let's Encrypt so far... But I guess in the worst case I can just buy traditional certificates for a couple of years.
- blattimwind 7y agoYou can literally exchange the certificates manually in the chain delivered by your webserver using a text editor.
- AnssiH 7y agoThere are no configuration options of any kind in Google App Engine with managed SSL security enabled (since the point is to let Google manage it), which I'd rather keep enabled if feasible to avoid having to worry about renewals etc.