Comment by Arbortheus
18 hours ago
According to this blog [1], it has now been almost 5 days since a researcher reported to Apple that the eMudhra CA certificates were compromised.
As I am writing, my iPhone 15 Pro is still accepting certificates signed by these compromised CAs. The device is "up to date", yet is still running Trust Store Version 2026073000. When I check at [2], certificates issued by 3 eMudhra Intermediate CAs are still being trusted!
Google Chrome revoked these certificates in 1 hour 40 minutes, Mozilla in just under 4 hours.
I am so astonished by how much Apple has failed here. There are potentially huge swathes of people completely oblivious that their phones are susceptible right now to being man-in-the-middle attacked.
Why does the iPhone not utilise a CRL list? Why does it take Apple 5+ days to do what Chrome did in under 2 hours.
It's a similar story for my MacBook, but at least there my Chrome browser _does_ use a CRL (the same can't be said for all the programs installed, however).
[1] https://fenko.nz/blog/emudhra-ca-compromise/#what-happened-i...
I pointed this out yesterday and people thought I was nuts:
https://news.ycombinator.com/item?id=50189521
I suspect Apple published no update and is relying on the CA's CRL and/or OCSP to do its job. But it's rate-limited, the connections time out, and iOS is hard-coded to soft-fail.
Like you my trust store is months old.
That said, I found separate installs of Firefox and Microsoft Edge that accepted *all* the bad certificates without a care.
The only browser that consistently rejected all of them was — you guessed it — Internet Explorer. A browser so old it couldn't even run the test properly but it did what it needed to and blocked all the servers.
To be honest, this whole experience has left me with a very sour taste in my mouth. It feels to me that the whole CA industry needs reform.
I am not smart enough to say how, but the sheer amount of work this created across the industry is monstrous. It probably has cost $billions to mitigate, and those mitigations have been slow and ineffective (see: my iPhone still being vulnerable).
In my experience, seemingly random pieces of software, libraries, and programming languages packaging their own CA stores has made this much harder to mitigate than simply running 'apt-get update ca-certificates'. We've practically just had to update every single thing to mitigate this.
Most of the stuff just seems/ feels to be (security) theatre. I actually disabled most of my OSCP, etc., for privacy reasons. No need to permanently send requests out to the web, when it won't help anyway when really required. I read HN to stay up-to-date and manually manage the certificates.
(Even with all the related options disabled, e.g., ocspd on OSX still regularly connects to random certificate related services to "check" on things. Something related to random root certificates I don't have in the system trust store or such, Not entirely sure what this is about and how to get rid of the requests in any other way than blocking things with Little Snitch)
The whole ordeal makes me wonder why the ergonomics/interface around CA trust management is not better.
It should be very easy and normal to ask for approval which is limited to the particular app, limited in time, and limited in scope.
Still keep defaults, but make it much smaller and put them under even higher scrutiny, certainly not 100 root certificates.
I don't understand why e.g. a CA for research institutions should be able to issue certificate for mybank.com or ecommerce.com and my browser would just trust that.
Should go back to the good old days when Verisign was the only provider and they cost $500 each
Firefox 158.0.1+ is the update that blocks them, are you running that?
I am and the test site says that Firefox is correctly rejecting them.
iOS absolutely uses a CRL, and Apple has revoked the eMudhra certs as of this morning: https://www.macrumors.com/2026/10/22/apple-blocks-certificat...
> Apple introduced the blocks on October 19
So actually 3 days ago.
It must be broken/buggy then.
For your own sake and the sake of anyone else who might be hitting this bug, I suggest you open applefeedback:// in Safari, file a bug, and post the FB number here or on the Apple Developer Forums.
10 replies →
… or you’re on a list
My phone still accepts 3 of the 14 chains. So something is broken.
Too old to edit… after restarting my phone all chains are rejected.
Do you have battery saving mode on? I think it blocks the background process that updates. I had the same issue but turning it off and waiting 1 minute started blocking all the certificates. This is for iPhone 13.
No battery saving for me.
> Your browser trusted 4 of 14 compromised certificate chains.
Just now on M1 Pro Safari.
On M1 Prp Firefox: none.
On iPhone 17: Safari: none, Firefox: none.
Hmm, on my MacBook Pro M4 Max I'd only tested on Chrome (which was fine).
I just tried on Safari, it still trusted 2/14 compromised chains.
Rubbish.
It's my laptop and I can't easily revoke the certificates myself.
edit: I went to keychain access app and found all emudhar and em signer certs -> there were four -> clicked get info for each -> under Trust section of the pop-ip -> selected "When using this certificate: never trust".
Now all checks on https://emudhra.we-have-a-problem.com pass for me.
My iPhone 12 is fine, so its not that Apple has done nothing, but there must still be issues with getting this to all devices?
Perhaps there's some bugginess, or it's a "staged rollout", however isn't the point of such a system to be rapid?
... 5 days later and I know better than to do online banking or messaging on my iPhone 15.
I'm pretty sure Apple does use CRLs, but for some reason your phone has a problem fetching them. Yesterday my iPhone SE running iOS 15.8.8 did connect to the sites, but refused to connect about 30 minutes later.
My previously working, then broken iOS and iPadOS browsers now work and have done for the last hour. Who knows why.
My iPhone 13 has all those certs blocked.
“Did not connect” for me, from your second link, on iOS 27.