TLS certificates (who vouches that a site is the one it claims to be)

The chain works in steps. The browser's list holds root certificates. A root signs intermediate certificates, and the intermediates issue the certificates of the sites themselves. It is enough for the browser to trust the root to accept whatever is signed below it along the chain. That is convenient: it does not have to know every site in the world. But it is also the weak spot, because a whole trusted branch depends on the keys of an intermediate certificate.

October 2026 showed what this means in practice. On October 17 Mozilla received a report that the private keys of eight intermediate certificates of the certificate authority eMudhra had been compromised. Mozilla writes that with them an attacker could issue fraudulent HTTPS certificates for sites they do not control and, if able to intercept a user's connection, impersonate the site and potentially read or modify traffic. Cloudflare, which also covered the case, says the keys themselves are weak and that it learned of the compromise on October 19. It is not a hole in a program, but leaked keys.

The browser does not wait for users to update. Mozilla blocked the certificates in Firefox through OneCRL - its central list of revoked certificates, which reaches users without an update or a restart. By 22:59 UTC the same day, less than three hours after the report, the updated list had reached everyone with standard settings. Cloudflare describes it this way: browsers fixed it with a flip of a switch, because most have a quick way to revoke, such as CRLSets in Chrome.

Trust in a certificate is only as strong as the key of whoever signed it.

What is left outside the browser

A browser is one application, while the software that checks certificates is in the hundreds. That is why Mozilla also released version 3.131.1 of its NSS list, which removes the root that signed the affected intermediate certificates - to protect the other programs that use Mozilla's list and do not receive OneCRL. Cloudflare warns that updating an SDK alone may not be enough: the check may live in a library, a language runtime, the operating system or a custom setting, and a successful test in a browser does not prove that a background service is protected. For its own services Cloudflare did not find active exploitation.

Our read: this is a related logic to DNS and DNSSEC (see the node on them) - a seal on trust that works as long as the key is with the right person. There it most often breaks when a key is swapped carelessly, here when a key leaks. In both cases the user sees nothing until they read it in the news.

The visual is generated code-art, no third-party images.