Assuming you aren't able to update via a custom ROM on unsupported hardware, it should still be possible to import the new Root Cert on Android.<p>> System-installed certificates can be managed on the Android device in the Settings -> Security -> Certificates -> 'System'-section, whereas the user trusted certificates are manged in the 'User'-section there. When using user trusted certificates, Android will force the user of the Android device to implement additional safety measures: the use of a PIN-code, a pattern-lock or a password to unlock the device are mandatory when user-supplied certificates are used.<p>Source: <a href="http://wiki.cacert.org/FAQ/ImportRootCert#Android_Phones_.26_Tablets" rel="nofollow">http://wiki.cacert.org/FAQ/ImportRootCert#Android_Phones_.26...</a>
I wonder if this will end up pushing the burden of CA root management to app developers on Android for apps other than browsers too.<p>This really seems like something worth decoupling from Android system updates – possibly even more so than emoji [0]?<p>Realistically, though, it's too late for Google to roll out something like this and we'll have to live with static copies of Mozilla's root CA set that will quickly go stale...<p>On the upside, it might convince apps that only talk to vendor-controlled backends (i.e. with a predictable set of CAs) to finally enable certificate pinning: If they need to think about their trusted root certs themselves, might as well only include the relevant ones.<p>[0] <a href="https://www.xda-developers.com/google-prepares-decouple-new-emojis-android-system-updates/" rel="nofollow">https://www.xda-developers.com/google-prepares-decouple-new-...</a>
See also: <a href="https://news.ycombinator.com/item?id=25008748" rel="nofollow">https://news.ycombinator.com/item?id=25008748</a>
It would be nice if you could send two end-entity certs, with the same public key, and different intermediates, and the other side would pick which ever one it liked.<p>Otherwise, you have to figure out which one root CA all your clients like, because it's probably hard to figure out which clients need which certs.
This article has some errors which are unfortunate.<p>> From the start, Let's Encrypt used a top-level certificate (known as a CA Root) that was signed by ISRG Root X1 and cross-signed by IdenTrust<p>Their "top-level" root is in fact ISRG Root X1. This was <i>not</i> cross-signed by IdenTrust (that wouldn't be impossible, several popular CAs took this approach, but ISRG, the people behind Let's Encrypt, did not).<p>The CAs which were cross-signed were the Let's Encrypt intermediates (sometimes called subCAs), so far these have been named Let's Encrypt Authority X1, X2, X3 and X4 and now just R3 and R4 (the name has to be sent over the wire every time you connect anywhere, and just "R3" is fewer bytes than "Let's Encrypt Authority R3")<p>[ Why are there intermediates? Well, an issuing CA has to be connected, albeit not directly, to the public Internet. That's obviously not the most secure situation conceivable. To protect the roots they can't be kept online, they usually live in dedicated hardware modules used only for relatively rare ceremonies like creating a new intermediate. Then the intermediates are kept online. If anything goes wrong it's relatively painless to distrust a mere intermediate, whereas distrusting a root causes massive disruption ]<p>Let's Encrypt provide a handy diagram:<p><a href="https://letsencrypt.org/certificates/" rel="nofollow">https://letsencrypt.org/certificates/</a><p>Anyway, what changes in January is <i>not</i> anything about the certificates you actually get from Let's Encrypt. Not one byte. What changes is essentially metadata, starting in January the Let's Encrypt backend system will by default stop giving subscribers a chain of certificates that proves this can be traced back to Identrust's DST Root CA X3, and instead give you a chain that traces back to ISRG Root X1.<p><i>Your</i> certificate is the same either way, for most people it will say it was issued by R3 (the shorter name I mentioned above, began being used at the start of December so many Let's Encrypt users haven't got a certificate from R3 yet but will do so automatically when next renewing). What changes is the accompanying certificate for R3 itself, there are two versions of that certificate.<p>If you need to service clients which don't yet trust ISRG Root X1 you can (tell your software to) continue to request the other version of R3 that's signed by Identrust's "DST Root CA X1" until later in 2021 when that expires.<p>But there is <i>no change</i> to the actual end subscriber "leaf" certificate and that's a mistake in the linked article.<p>I thought we might see a HN link for Let's Encrypt new intermediate R3 going live in the middle of the week, but we didn't. So I guess that means it went so well that nobody even noticed.
> but the key problem is dealing with older operating systems that either don't have the correct root certificate, or don't have support for either the SHA-1 or ECDSA protocols that are used in the process of verifying a certificate.<p>Say what now? Pretty sure sha-1 support for certs is much older than android 7.
Yeah, this is 1 month old: <a href="https://letsencrypt.org/2020/11/06/own-two-feet.html" rel="nofollow">https://letsencrypt.org/2020/11/06/own-two-feet.html</a>
I wish there was a way to have multiple certificates (1st preference, 2nd for failover) so you can support two or more at at time - with feedback on how many using the failover. Its stressful to make a switch and then see what is broken.