Let’s Encrypt to transition to ISRG root
scotthelme.co.uk
scotthelme.co.uk
"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?
But I guess in the worst case I can just buy traditional certificates for a couple of years.
Morally is the easy one. If you work for a public CA you presumably think that the Web PKI is a good idea, and Let's Encrypt helped bring that benefit to lots more users, so that's a good thing. Consider the question of whether McDonalds should support a local soup kitchen. McDonalds thinks food helps bring people together, so why not?
Pragmatically, there are a number of benefits to Let's Encrypt for a commercial CA. It creates a "brand halo" for the "SSL Certificate" product class that you benefit from, where positive experiences with Let's Encrypt result in more customers for you. Growing the market means more opportunities for you as a seller. I see some misleading analysis of the "SSL Certificate" market that doesn't include "Does not have a cert" as one of the options. So they see Let's Encrypt crushing other outfits and assume that's got to hurt profits. But a site that goes from nothing to a Let's Encrypt cert makes no difference to sales at the for-profit CA. Even if 100 sites do that, if just one copies them but chooses to buy a cert, that's an extra sale they would not make otherwise.
(DigiNotar, of course, famously gave out a fraudulent * .google.com cert and is now defunct.)
As a CA you're assuming a whole lot of liability for not that much money (not that much at the scale of even a small business, anyway), and that just doesn't seem like it'd scale to a wildly profitable venture, especially considering the kinds of people who are actually well equipped to run a CA can probably make a lot more money doing basically anything else in web security. When you add up the contingency risks, the opportunity costs, and whatever actual day-to-day business expenses, it does seem like you'd be looking for other ways to make more comfortable profits.
That doesn't mean CAs should charge more or anything, just that I could accept that SSL certs for standard websites isn't what anyone with a good vision for their business is really trying to hold onto.
Because most businesses, if you ask them "How much $$$ to destroy your business?" will respond "absolutely loads"
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.
IdenTrust has OV, EV, managed PKI, and even DV certificates with 2 year validity that some legacy organization infrastructure requires.
I was wondering what impact if she, a board member of ISRG, has to comply with the Australian encryption laws?
To that end, it was added to NSS 3.26/Firefox 50 (November 2016) and to Chrome 57 (March 2017).
On iOS, it was first added in iOS 10 (2016).
The root itself was created in June 2015.
Edit: they also have a list on their website - https://letsencrypt.org/docs/certificate-compatibility/#know... . It lists Android < 2.3.6 as being incompatible .. I wonder if that's updated for the non-cross-signed intermediates.
So Windows XP...
There are a lot of old systems out there running API's, automation, industrial systems, etc. They never get updates, and are expected to last decades. Most of them aren't on the public internet, but HTTPS would still be a good idea. This change is going to mean a bunch of them just get changed over to having no encryption.
Though I imagine that's extremely expensive. I expect that has something to do with this decision - they are a non-profit after all.
This is going to cause a lot of stuff to break, and it's 100% LE's responsibility.
HN's root cert is valid through 2038.
LE could have gotten cross-signed by a cert that didn't expire so soon, but they didn't.
And they still could.
Expecting XP or say Windows 98 to still work on modern day standards is just laughable.
Upgrade, or get left behind. The concept of 'never updating' isn't one that is practical and you'll pay the penalty for it later on.
I also know that we get a number of students connecting with Android v3 or earlier from these same locales.
I found Linux Lite, based on Ubuntu 18.04 LTS:
Or, for industrial use a hundred bucks on a certificate from an older CA is nothing.
Just tested with the new LE root cert and it doesn't work.
LE says "it's CA problem, not a Let's Encrypt problem", but that's disingenuous.
Let's Encrypt chose to get cross-signed by a root that expires in a couple years.
For example, HN's root doesn't expire until 2038.
This is definitely a Let's Encrypt fuckup that will cause many sites and apps to break.
If its that important to you or if its a commercial offering in an 'industrial setting', you should have no problems acquiring a cheap SSL certificate from another source. You can literally get them as low as $6 a year right now.
LE provides a great service and continues to do so. If you want to nitpick, then jump to a 'competitor'.
Sure, I can solve the problem by switching to a different CA, or by adding the ISRG root cert to each device.
But this is a problem that didn't need to happen. I blame myself for not anticipating it when I selected LE.
And I blame LE for cross-signing with a root cert that expires so soon. Not a good choice for a new CA that will take many years to be trusted on most devices.
https://nvd.nist.gov/vuln/search/results?adv_search=true&for...
Good point. Generally it’s a bad idea for users to install any CA certificates on their devices, but in this case I think it makes sense.
People with other versions of Android and iOS can test and report here?
- FAIL Galaxy Tab 4 7" (SM-T230) Android 4.4.2
- FAIL Galaxy Tab A 7" 2016 (SM-T280) Android 5.1.1
- SUCCESS Galaxy Tab A 9.7" (SM-T550) Android 7.1.1
- SUCCESS Galaxy Tab A 10.1" (SM-T580) Android 8.1.0
I don't have any Android 6 device at hand, but this is consistent with @regecks statement "On Android, the root was first added in Nougat" (which is Android 7).
This is going to be problematic, as there are still devices currently for sale on Android 5/6 (such as the aformentionned Galaxy Tab A 7", which doesn't have a replacement on some markets).
My wife runs a blog which generates substantial income and uses certs from Let's Encrypt. It's a non-tech blog with primarily US readership. Checking stats for this month, 7% of all visitors were using Android 4/5/6 (20% of all Android users). The percentage of users on old Android running Firefox was basically nil. Losing all these users would be very costly.
Hopefully certbot will be modified so it is possible to pick the current intermediate during automatic renewal. If I have to do a manual operation to switch intermediates each time the cert renews (currently done by cronjob) then it is probably safer (operationally speaking) to just buy a cert.
I don't really understand why Let's Encrypt is making this change now. Sure, the current root is expiring "soon", but not until September 2021. Switching roots could be safely pushed off to early 2021 at which point hopefully most of these older Androids would be cycled out.
An SSL cert can be purchased for as low as $6 a year; if this is important to you, try buying one of those.
Edit: fortunately it looks like certbot plans to support using the old intermediate https://github.com/certbot/certbot/issues/6971 so this should not prove necessary.
The issue is not so much about the browser, as I'm an app editor (which happens to also sell tablets with our apps preinstalled to reduce friction). The issue is that apps that rely on the device certificate store aren't going to be able to use https with a server using a Let's Encrypt certificate issued with the new root CA.
Shipping a root certificate store would be (for my scale) a bad practice. I made the mistake of pinning a SSL key in the past, never again (you run into issues when your clients never even connect the device to the internet in 3+ years, and then your updater doesn't work anymore).
Fortunately for me, I don't currently use Let's Encrypt for my API servers, and that news was the last straw to make the boss decide we will stop selling Android 5 devices.
Unfortunately, this means our users who recently bought those devices will have some third-party apps might be broken starting 9th of July, and some sites will give a scary warning.
If I recall correctly, Android >=5 has pretty decent support for modern crypto (such as TLS V1.2, ECC). So, Android 5/6 could still just work, if the vendor is bothered to update the CA root store.
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.
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.
On my blog ( 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.
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.
Seems to suggest "yes"
lego \
--email="info@example.com" \
--accept-tos \
--path="./ssl" \
--domains="*.example.com" \
--dns="route53"
Personally, I would not want to do that.
However, because the DNS check doesn't require writing to the webroot, you could run this on any server you like and then distribute the certificate to your edge nodes (meaning your edge nodes don't need to have access to write to your DNS). Some clients even have scripting hooks which could make this significantly easier.
(I assumed the "store my cloudflare API keys on my web host" aspect was your main concern with this method -- not necessarily who wrote the client because there are plenty of other clients.)
"This release introduces support for wildcard certificates, a new offering from Let's Encrypt. Getting a wildcard certificate requires enabling the DNS challenge. Fortunately, that is extremely simple with Caddy, and it works with over 20 different providers!"
The problem I found is that you need a DNS provider that not only has an API, but also has a fairly predictable propagation of DNS changes. I noticed through trial & error that contrary to the specs, let's encrypt doesn't wait and retry if it doesn't find the right DNS entries when it validates the DNS authorization request, instead it just fails the whole thing. Which means that you need to be pretty certain the change has propagated before you tell let's encrypt to complete the authorization. In my case I am using OVH, which has two tiers of service, a regular DNS which is fairly predictable, and a "Anycast DNS" offering which I found to be very hard to get let's encrypt to work with.
Also a rookie mistake to avoid: “* .domain.com” doesn’t cover “domain.com”. So you kind of need to get two authorizations, one for “* .domain.com” and one for “domain.com” and then get a cerficate that covers both (if that’s your need).
Why not just fetch a different cert for every subdomain you use? It's also better security practice as this allows you to use different key per subdomain and the possibility to revoke bad or unused certs.
I could get around it by hosting split dns, but that’s quite messy
Even on those that are reachable I’d have to carve out port 80 and forward it somewhere else to do the cert generation.
Another option would be dynamic server names - where the host part contains a lot of information (or no info)
https://gafjsisi.slashdot.org I suspect has never been loaded before today. It seems to work from my phone so I assume it’s a wildcard cert
Also, if for some reason the automated process fails, I'd rather have one subdomain go down, than all of them.
> If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 5,000 unique subdomains per week.
This was one of the reasons for me switching to Cloudflare DNS, although many other providers should work too.
https://github.com/joohoi/acme-dns is a server implementation of that, and a number of popular clients support it. Or if you don't want to run acme-dns, some ACME clients support an "alias" mode that essentially does the same thing using generic DNS CNAMEing.
Annoyed that Route53 IAM still doesn't let you limit the record label ...
Have a separate machine that isn't publicly addressable generate the keys and request the certificates, and then push them out to where they need to be. You don't even need to give that box privileged access to the places the certificates need to be, if you arrange things right. Only one box then needs your API key.
Depending on your scenario it may well make more sense for the DNS privileged machine not to know the keys, and be given Certificate Signing Requests (CSRs) for the certificates it's to go get from Let's Encrypt. Most good ACME clients will accept a CSR you provide as an alternative to making their own keys or using a private key you generated.
A CSR is a signed document like a certificate, but instead of being signed by a CA (Let's Encrypt) to certify something, they're signed by "you" (ie using your private key) to prove you know the key and you want a certificate with these names on it.
Under the hood the ACME protocol always uses CSRs, but since tools to make them are often clumsy and nasty clients tend to follow Certbot (the reference client) in defaulting to making their own CSR without you needing to know about it, a client can do this because it knows your private keys. By providing your own CSRs you don't need the box speaking ACME to know your private keys.
Let's Encrypt doesn't care if you provide the same CSR repeatedly for renewals, unless your private key is known to them because somebody leaked it, in which case subsequent requests for a certificate will fail, which is what you want since that key is now compromised and you need to replace it. You should rotate keys anyway, but can do so at a pace which is appropriate to your risk factors e.g. once a year is fine for most people, and not dictated by the rate at which Let's Encrypt renewals happen.
That and I've not played with doing that myself yet, so while I know it is possible I can't talk about it authoritatively.
Compromising a web-server will thus not compromise my DNS.
It’s just a basic setup with dehydrated[1], some bash scripts for deployment and cron though.
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/
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