Abstract:
Apple recently blocked eight digital certificates with serious security issues on iOS and iPadOS devices to prevent attackers from using these certificates to disguise themselves as legitimate websites and then carry out phishing, man-in-the-middle attacks or steal user data. However, security researchers remind that some macOS system tools may still trust these problematic certificates, and Mac users and system administrators still need to pay attention to subsequent security updates.
This incident involves eight intermediate certificates issued by eMudhra, an Indian certificate authority. Digital certificates are an important part of the Internet security system. When a browser accesses a website, it will use the certificate to verify the identity of the server and protect data transmission through HTTPS encrypted connections. For example, when a user visits a bank website, the browser needs to confirm that the connection is indeed to the bank server and not a fake website set up by an attacker.
Normally, certificate authorities must use cryptographic keys that are strong enough to issue certificates to ensure that unauthorized third parties cannot spoof the identity of a trusted website. However, security researchers discovered that the eight certificates involved in eMudhra had extremely serious key generation problems, and their private keys turned out to be integers less than 256. This means that an attacker only needs to try a very small number of possible values to have a chance of recovering the relevant private key, with almost no need for complex calculations.
According to Mozilla's investigation, these private keys are extremely easy to guess. For modern cryptography, this situation is equivalent to using an extremely simple number as an account password, which is completely unable to provide normal security. Once an attacker has the relevant private keys, it is possible to forge other certificates issued by these certificates, making the affected software mistakenly think that the connection is to a legitimate website.
The danger of this type of attack is that the attacker does not necessarily need to directly compromise the target website's server. If a trusted HTTPS certificate can be forged and combined with network traffic interception and other means, an attacker may impersonate a bank, enterprise, or other legitimate website, and induce users to send passwords, identity information, or other sensitive data without their knowledge. Attackers may also modify the content of web pages received by users to further commit fraud or spread malware.
The related issue was reported to the browser security team on October 17, 2026. Google, Mozilla and other manufacturers subsequently took measures to prevent the affected certificates from continuing to be trusted. Mozilla distributes protection information through Firefox's OneCRL certificate blocking mechanism. Users usually do not need to manually update the browser or restart the device to obtain relevant protection. Google has also updated Chrome’s certificate blocking mechanism and taken restrictive measures on related certificates.
Apple began to deploy relevant blockade measures on October 19. According to security researchers, these measures prevent software that relies on Apple's system certificate verification mechanism from trusting the affected certificates. Apple took action slightly later than Google and Mozilla, but the relevant certificates have now been included in the blockade.
It is worth noting that not all of these eight certificates are used for website HTTPS connections. Six of them are TLS-related certificates, and the other two involve code signing purposes. Code signing certificates are used to verify the identity of the software publisher and whether the software has been tampered with. Therefore, serious flaws in the certificate private key may also have an impact on software distribution and trust systems.
However, there is currently no evidence that attackers have used these certificates to carry out actual attacks. Security researchers pointed out that although the certificates in question have serious flaws, not all of them have been used in production environments. Google also stated that before it took the blocking measures, no TLS certificates issued by the six affected intermediate certificates and entered into relevant log records were found in the public Certificate Transparency logs. This somewhat reduces the risk of abuse of known public HTTPS certificates, but does not completely rule out the potential impact in other software or non-public environments.
For Mac users, the situation is a little more complicated. Although Apple has taken blocking measures, Mozilla cryptography engineer Dennis Jackson pointed out that macOS's built-in command line tool curl may still have trust issues. The set of certificates used by this tool does not check the revocation information of related certificates, so in some cases curl may continue to accept certificates even if they have been declared invalid.
This means that scripts, development tools or automated services that rely on macOS's built-in curl for network requests may need to additionally check their own certificate verification behavior. Especially for systems that have accepted relevant certificates, you should pay more attention to whether the certificate blocking measures actually cover the software and trust storage mechanism used.
For ordinary users, the safest approach is to promptly install system and software security updates provided by Apple and keep the browser at the latest version. Enterprise administrators and developers should check whether servers, command line tools, applications, and custom certificate stores still trust the affected certificates and follow detection and mitigation recommendations provided by security researchers.
This incident also exposed an easily overlooked problem in the digital certificate system: even if HTTPS uses a mature encryption algorithm, if the private key used in the certificate generation process is too simple, the entire identity verification system may still be easily broken through. The encryption technology itself does not fail. The real problem lies in the key generation and certificate management links.
eMudhra stated that there is no evidence that its infrastructure has been compromised, and no relevant data leakage has been discovered. The agency is working with potentially affected customers to assist in replacing relevant certificates. Since these certificates were generated in April 2025 and the problem has existed for more than a year, relevant agencies need to further confirm whether other software, systems or services have relied on these certificates to establish trust relationships.
Overall, Apple's blocking of these eight certificates is an important step in thwarting potential attacks, but certificate revocation does not mean that all software will immediately stop trusting them. For ordinary users, timely updating of systems and browsers is usually the most direct protective measure; for developers and enterprises, it is necessary to further check the certificate verification mechanism to ensure that all relevant applications can correctly identify expired certificates.
Comments