The key was 4: who decides which websites your software trusts

Last updated: 25 October 2026 · 18 min read

We have a problem here

On Saturday 17 October 2026, at 18:05 UTC, Chrome’s root program received a report from a security researcher who has been identified in public only as Wayne. He claimed to hold the private keys of eight certificate authorities run by eMudhra, a listed company based in Bengaluru, India. To prove it, he had used each of the eight keys to sign the same short message: “We have a problem here – Wayne.”

He had not needed to break into anything. Once the news was out, the security researcher Scott Helme described what the keys looked like. One of them was simply the number 4. Two others were 56 and 115. Helme said he had recovered all of them from their public certificates on his laptop, and that it took less than a second. An independent check by journalists confirmed that the private key behind eMudhra’s “EM OV TLS CA – G3C” was 4.

The eight were intermediate certificate authorities, the working layer of a certificate company that signs credentials for other people. Six of them were authorised to issue certificates for websites, and those six were trusted by the root programs of Chrome, Mozilla, Microsoft and Apple. The other two were for code signing, the certificates software makers use to sign their programs, and were trusted by Microsoft. Their keys had been generated incorrectly, so anyone who knew where to look could compute them from the certificates themselves, which are public by design. That had been possible since the certificates were created in April 2025.

At 19:45 UTC, an hour and forty minutes after the report arrived, Chrome had confirmed the findings and pushed a block to its users. Nobody had to install an update or restart the browser.

The speed mattered because of what such a key can do. Someone holding any of the six website keys and able to intercept a person’s connection could present a forged certificate for a bank, an email service or any other site, whichever certificate company the real site used, and software that trusted eMudhra’s chain would accept it. Two main protections stood in the way: a public logging system called Certificate Transparency, which some software insists on and much does not, and whatever blocks each piece of software received in time.

Whether a forged certificate would have worked depended on decisions that are normally invisible: who vouches for a website, who decides that the voucher should be believed, and how fast that belief can be withdrawn when the voucher turns out to be broken.

What a certificate vouches for

A website certificate is a small signed document that ties a name, such as a bank’s web address, to a public key. Public keys come in pairs with private keys. The private key stays secret and produces digital signatures; the public key lets anyone check that a signature came from its partner. When your browser connects to a site, the site proves it holds the private key that matches the public key in its certificate. The certificate itself says that this public key belongs to this name, and a certificate authority, or CA, stands behind that statement by signing it.

Before signing a website certificate, the CA must check that the applicant controls the domain. One approved method is to give the applicant a random value and then look for it in the domain’s DNS records, the internet’s public address book, where only someone who controls the domain could have put it. The CA may also confirm that the applicant really holds the private key it wants certified, using a technical test called proof of possession, although the underlying standard also allows it to rely on the applicant’s word.

No browser could check every CA in the world for itself, so trust is delegated in a chain. At the top sit root certificates, held in a list called a trust store that ships inside your operating system or browser. Roots authorise intermediate CAs, and the intermediates issue the certificates that websites use. When your software sees a site’s certificate, it follows the signatures upward, from the site to an intermediate to a root, and accepts the site only if the chain ends at a root in its store, every signature checks out, the certificate is in date and covers the name being visited, and none of the software’s other rules forbids it.

Root programs, run by operating system and browser vendors such as Apple, Google, Microsoft and Mozilla, vet certificate authorities and decide which roots go into the store. That is why an intermediate’s private key is so valuable. Unless it has been restricted to certain names, which eMudhra’s had not, an intermediate can sign a certificate for any domain, and that certificate verifies upward to a trusted root. The root’s own key can stay locked away; the intermediate’s key does the daily signing, and if it leaks, the root’s endorsement leaks with it.

None of this tells you whether a website is honest, although the browser’s lock icon is widely taken to mean it does. When Google studied the question in 2021, only 11% of participants correctly understood what the lock meant, and nearly all phishing sites used HTTPS and so displayed it too. In 2023 Google announced that Chrome would replace the lock with a different icon. A basic certificate says only that the connection goes to whoever holds the key for that name. Some certificates also name the organisation behind the site; none vouches for its intentions.

There is one more layer. Certificate Transparency, set out by Google engineers in 2013, puts certificates into public logs where anyone can audit what each CA has issued. Its designers intended that clients would eventually refuse any certificate that had not been logged, so that a certificate kept out of the logs, whether issued by a CA or by a thief with a CA’s key, would be refused. Chrome does this by default for every connection that relies on its root store.

The warning that went unanswered

The rules for making CA keys are strict. For roots and certain intermediate keys, the industry’s Baseline Requirements, the rulebook that browser root programs and CAs maintain together, say the CA must follow a written key generation script and have a qualified auditor witness the ceremony or record all of it on video. Any CA key must be generated by several people together, none of whom holds all the knowledge needed to do it alone.

On 30 April 2025 eMudhra created a batch of 24 intermediates. They came in three series, labelled A, B and C, with two kinds of key, RSA and the elliptic-curve type called P-384, and four purposes. The eight broken keys were all the P-384 keys in the B and C series. All eight were whole numbers smaller than 256. Written out in full, each was a long row of zeroes with something in the last byte.

Why this key was guessable

A private key on the P-384 curve is simply a number, chosen at random between 1 and a fixed limit that is itself 384 bits long. The public key is computed from the private key by a calculation that is easy to perform forwards and, for a properly random number, hopeless to run backwards. It is printed in the certificate. The number 4 is a perfectly legal private key; it is also one of the first numbers anyone would try. Mozilla pointed out that keys this small can be recovered near instantly: compute the public keys for 1, 2, 3 and so on up to 256, and compare each with the one in the certificate. When two match, the private key is whatever number you started from. A properly random key offers no such short list. As Scott Helme put it, the range holds roughly 10 to the power of 115 possibilities, "so nobody is ever going to search that." Mozilla's Dennis Jackson also handed the task to AI agents running locally. They recovered the key on their first attempt from a simple prompt.

How did a key ceremony produce numbers that small? eMudhra’s preliminary explanation, posted on 19 October, is that the script it used that day had a flaw. It says it had approved a one-off change to the usual procedure to test exporting the keys, that a coding error made the hardware create a second, weaker pair of keys alongside the proper ones, and that the weak keys were then used by mistake to request the certificates because their labels looked similar. It says the keys were generated in hardware security modules made by Utimaco, the tamper-resistant devices meant to produce and guard CA keys.

eMudhra calls the account preliminary, and it leaves the central puzzle open. One commenter on Mozilla’s public bug noted that either the keys were made outside the secure hardware and loaded into it, against policy, or the hardware could somehow be configured to make defective keys itself. Another participant, on Mozilla’s public mailing list, suggested without confirmation that software had mistaken a small file pointing to the real key inside the hardware for the key itself. Mozilla, trying much harder, could not recover the P-384 keys of the A series from the same batch. It sent eMudhra questions on 20 October with a 24-hour deadline; by 23 October it had received no answer, and how the weak keys came to exist had not been explained.

What is documented is that the problem had shown itself more than a year earlier. In June 2025 a public monitoring service showed eMudhra serving six certificate revocation lists with invalid signatures for these same intermediates. A revocation list, or CRL, is a signed register of certificates a CA has cancelled, and its signature must verify against the public key in the CA’s certificate. eMudhra’s report at the time said that Sectigo, another certificate company, had first warned it by email on 3 June 2025, and that the message had been quarantined by internal filters and not seen. The faulty lists were replaced on 6 June.

In October 2026 eMudhra explained what that fix had been. The lists had first been signed with the original, properly random keys; because the certificates held the public halves of the weak keys, those signatures failed, and the company re-signed the lists with the flawed keys. In June 2025, then, eMudhra had evidence that its certificates did not match the keys it thought it was using, and it fixed the lists.

Chrome’s root program asked why eMudhra had simply re-signed the lists instead of halting operations, investigating why two key pairs existed for these CAs and revoking the certificates. eMudhra says its roots and issuing CAs went through independent audits two years in a row. On 14 October 2026, three days before Wayne’s report, it published a revocation list for a different root, emSign Root TLS CA – G1, whose signature did not verify either.

Two kinds of off switch

Chrome’s first move was fast because it targeted keys. Chrome keeps a blocklist called a CRLSet, which Google pushes to browsers in the background. The update it landed at 19:45 UTC blocked the fingerprints of the six intermediates’ public keys. Because the block named keys, it covered every certificate that used those keys, including any that a forger might create later. Mozilla blocked the certificates in Firefox through its own list, OneCRL, and finished at 22:59 UTC. OneCRL works without users updating or even restarting Firefox.

A list pushed in the background only protects the software that receives it. On 20 October Mozilla released a Firefox update for users whose configurations had kept the blocklist from arriving, and later a fix for some Firefox for Android profiles that were not applying it. Google began sending an equivalent block to Android devices through Google Play Services around 22:00 UTC on Monday 19 October, and said the next day that most had received it. Microsoft and Apple followed within days, although published accounts disagree on the exact date of Apple’s action.

The certificate authorities moved too. eMudhra marked all eight certificates revoked by 09:38 UTC on 18 October, with the reason given as CA compromise. Sectigo, which had cross-signed the intermediates, finished revoking its cross-certificates on 19 October. Chrome also arranged for the Certificate Transparency logs to reject any certificate chaining to the compromised CAs, so that a forged certificate could no longer collect the log entries that CT-checking software demands.

The heavier tool is to remove the root that authorised the intermediates. On 20 October, noting that several people had by then recovered the keys independently, Mozilla decided on the emergency removal of emSign ECC Root CA – G3, the eMudhra root above the broken intermediates, from its trust store. Firefox did not need it; OneCRL already covered Firefox. It was for everyone else who uses Mozilla’s root list or one derived from it without OneCRL. Mozilla warned that the change would make some servers unavailable to those users until the servers moved to new certificate chains.

Chrome removed the same root from its store. Google expected the change to reach all devices relying on the Chrome Root Store on Tuesday morning, 27 October 2026, Pacific time, and sooner on the Canary and Beta test versions. Google said plainly that some legitimate certificates chaining to that root would stop working in Chrome as a result.

The two switches differ in what they catch and whom they hurt. A root removal cuts every path through that root, including those of honest websites, but misses paths through other roots, and eMudhra’s intermediates had another. Sectigo had cross-certified them, linking the same keys to a root called AAA Certificate Services, issued under the Comodo name. Chrome had dropped that root in April 2025, but some systems still trusted it: Ubuntu removed emSign ECC Root CA – G3 from all its supported releases and, from older releases that still carried it, the Comodo root as well. A block keyed to the intermediate itself catches every route at once. The Go programming language took that approach: from versions released on 19 October, Go’s certificate checker filters out any chain containing one of the compromised intermediates, whatever root it ends at.

Everyone else’s update

On 18 October Mozilla wrote in its public bug that it was worried about the wider ecosystem, because many endpoints have no effective way to receive revocation information. Browsers had their background lists. Much other software that makes secure connections has nothing like them.

The incident tracking site, a public page set up by Mozilla’s Dennis Jackson, spelled out who was exposed. Applications and libraries that ship their own bundle of trusted roots needed software updates. So did apps built on Electron, the framework behind desktop programs such as Slack and Discord, which pick up Electron’s fix only when they are rebuilt on a patched release.

Some gaps sat in operating systems’ own trust files. As of 22 October, the incident site said that macOS blocked the compromised intermediates, but that its built-in command-line tools, including curl, git and python3, checked certificates against a separate file without consulting revocation, and that file had not been updated. On Ubuntu, Java’s trust store needed manual action after the system update because of a synchronisation problem that Canonical had not resolved by 22 October, and browsers installed as snap packages did not use the system store at all.

Other gaps sat in libraries that carry their own lists. Go shipped its fix as security releases 1.27.3 and 1.26.10, under CVE-2026-111943. Python’s widely used certifi bundle removed all four emSign roots on 18 October, then restored the three that were unaffected in a release tagged 2026.10.19; an automated release on 23 October dropped two of those three again. And some products could be fixed only by their makers: Cisco’s Talos security team singled out virtual private networks as likely to need updates.

Underneath all of this sat Certificate Transparency. Most browsers enforce it, but many non-browser clients, including curl, do not. A forged certificate made with one of the eMudhra keys and never logged would be rejected by Chrome but could be accepted by those clients, as long as they still trusted eMudhra’s chain and nothing else stopped it, such as an app that accepts only its own servers’ known certificates.

There is a strong case that the system worked. No website certificates chaining to the six intermediates were logged to Certificate Transparency before Chrome’s block on 17 October, so between the creation of the keys in April 2025 and that block, no forged certificate from them could have been used against clients that enforce CT. Talos said it had seen no malicious use in the wild as of 21 October, 14:00 UTC. eMudhra says only one of the affected intermediates was ever put into production, and that none of them ever issued a certificate to a website or a software maker.

For software that enforced CT the whole time, that argument is right, and the protection came from a standing rule, not from the weekend’s emergency. Its reach is narrower than the phrase “the system worked” suggests. Firefox for Android began enforcing Certificate Transparency only with version 145, first offered to users on 11 November 2025. Android apps can use built-in CT checks only from Android 16, and get them by default only when built for Android 17.

The emergency also mattered for what came after. Mozilla’s first notice to the downstream maintainers of trust stores deliberately did not say that the keys could be recovered by anyone. By 20 October that hardly mattered: several people had recovered them independently, and Helme had published all eight of the values. Once the keys were effectively public, the blocks and the CT-log rejections were what stood between them and any new forgery. By 24 October, nothing published showed whether attackers had used the flawed keys against non-CT clients between April 2025 and October 2026.

Who holds the switch

Decisions about which roots browsers and operating systems trust belong to the root programs, and the programs’ rules give their owners wide room. Chrome’s policy says Google includes or removes certificates “at its sole discretion”, and that each included certificate must provide value to users that exceeds the risk of keeping it. Mozilla’s policy says it may disable or remove a certificate at its sole discretion, at any time and for any reason. Mozilla also says it charges no fees for inclusion.

That discretion has been used in different ways. In 2014, after India’s National Informatics Centre issued unauthorised certificates for several Google domains, Chrome did not throw out the India CCA root above it. It limited that root to a list of Indian domains. Three years earlier the response to a Dutch authority had been total: on 3 September 2011 Google decided to reject all of the certificate authorities operated by DigiNotar, and seventeen days later a Dutch court declared the company bankrupt.

DigiNotar, 2011

DigiNotar's breach became public through an ordinary user. On 28 August 2011 a customer of ParsOnline, an Iranian internet provider, posted on a Google support forum about a certificate warning that Chrome had shown him. The certificate claimed to be for Google, and it had come from DigiNotar, whose systems had been broken into. Investigators from the security firm Fox-IT, working for the Dutch government, later found that a rogue certificate covering google.com addresses had been used in a large attack on approximately 300,000 users, almost all of them in Iran, whose Google traffic was probably intercepted or redirected. They derived that estimate from 298,140 distinct internet addresses that had checked the forged certificate's status, and called it a very rough approximation. On 3 September the Dutch government publicly revoked its trust in DigiNotar. No attack using the eMudhra keys had been reported by late October 2026. DigiNotar showed what a CA's signing power does in the hands of someone willing to use it.

Inclusion in Chrome’s root store, Google wrote, requires a CA owner to continuously demonstrate the technical competence and operational rigour needed to protect Chrome users, and it said it was “closely investigating” whether eMudhra’s remaining CA certificates should stay. On 23 October eMudhra told the public bug that intense social media scrutiny and analysis by investors and customers had made meaningful analysis of the event “pretty much impossible.” Chrome replied the same day that this was no excuse, and that eMudhra still owed obligations to the “billions” of people who rely on the system, people its mistake had exposed.

eMudhra’s board had already decided, on 22 October, to withdraw from the global SSL/TLS certificate business. The company says that business is a very small part of its operations.

The same companies also write shared rules with the CAs at a body called the CA/Browser Forum. In a ballot that closed on 11 April 2025, nineteen days before eMudhra generated the flawed keys, Apple, Google, Microsoft and Mozilla all voted to shorten the lives of website certificates, and 25 certificate issuers, eMudhra among them, voted yes as well. The ballot’s case was that revocation does not adequately protect people at internet scale, while expiry does. “Certificate validity periods, and their enforcement by relying parties, are incredibly reliable,” it said. Under the rules in force in October 2026, website certificates issued from 15 March 2026 may last at most 200 days; from 15 March 2027, 100 days; and from 15 March 2029, 47 days.

Those caps apply to the certificates websites use, by the date they are issued. The rule’s text does not cap the CA certificates at the centre of this incident, so shorter lifetimes would not have expired eMudhra’s intermediates. Nor has revocation gone away. Let’s Encrypt, the free certificate authority, shut down its OCSP service, which let browsers ask about one certificate at a time, in August 2025, because each query told the CA which site was being visited from which internet address. The emergency blocks of 17 October were, in effect, revocation lists that browser makers curated and pushed themselves.

The arrangement puts a great deal of power in a few private hands, most of them American. What the eMudhra case shows is how that power is exercised: in an open bug where anyone can read the questions, the deadlines and the replies, with the reasons published by the companies doing the removing.

The certificates that have to move

Removing a root is quick to announce and slow to absorb. As of 21 October, Chrome counted about 30,800 unexpired precertificates chaining to emSign ECC Root CA – G3. A precertificate is the copy of a certificate submitted to the transparency logs before issue, so the figure is a count of logged certificates, not of websites still running them. Of those, 30,791, or 99.9%, came from two intermediates belonging to InCommon, a certificate service run by Internet2, a US networking organisation. Those two were not among the eight broken intermediates; they simply hung from the root being removed. eMudhra estimated that about 30,000 certificates needed to move, almost all issued through ACME, the protocol that lets servers request and renew certificates automatically. eMudhra stopped issuing under the G3 root on 20 October.

Automation does not solve this by itself. Standard ACME clients replace a certificate only when its renewal date comes round, unless they support a newer extension that lets the CA ask for early renewal or someone intervenes by hand. Chrome pointed out on 21 October that moving from eMudhra’s elliptic-curve hierarchy to its RSA one may also mean changing the client’s settings.

InCommon’s certificates come through CertiNext, a supplier whose parent company is eMudhra. On 22 October InCommon told its subscribers that many of them had spent the week responding to certificate errors and planning around changes outside their control, after a successful but draining migration over the spring and summer. Its advice that morning was to reissue affected certificates as RSA until elliptic-curve issuance was restored.

eMudhra had said on 20 October that the only alternative for its G3 customers was intermediates chaining to its RSA root, emSign Root CA – G1. Mozilla said the same day that it was not removing trust in G1 at that time. G1 was among the remaining eMudhra certificates that Chrome said on 20 October it was closely investigating; by 24 October Chrome had announced no decision. On 21 October Chrome asked eMudhra to confirm whether customers were being moved to G1, to another company’s hierarchy, or to both.

InCommon’s update on the evening of 22 October dealt with the immediate problem. Elliptic-curve certificates were being issued again, now chained to the G1 root, and existing clients could renew without any change to their settings. The same update said that eMudhra would stop issuing from any intermediate chained to its public roots in 30 days, on a date CertiNext would confirm, and that InCommon was working on a replacement path. For subscribers who had finished one draining migration over the spring and summer, the removal of a single root had started another.

Related articles

• How far a US sanctions list reaches into a court in The Hague
• What’s next for Bitcoin?
• How AI actually works: what the developers know that the headlines don’t

Further reading

As an Amazon Associate, Eikleaf earns from qualifying purchases. The book links below are affiliate links: if you buy through them, we may earn a small commission at no extra cost to you.

• The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography — Simon Singh (1999). Accessible history of cryptography that explains public-key encryption, the maths behind the certificates and private keys in the article.
• Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.) — Ross Anderson (2001). The standard reference on how real security systems fail, with chapters on public-key infrastructure, certificate authorities and trust.
• Secrets and Lies: Digital Security in a Networked World — Bruce Schneier (2000). A leading security writer explains, without maths, why digital certificates and trust chains are only as strong as the organisations behind them.

Recommended videos

Gen AI Disclaimer

Some contents of this page were generated and/or edited with the help of a Generative AI.

Media

HTTPS and padlock in website address bar – Wikimedia Commons (Photo: Santeri Viinamäki, CC BY-SA 4.0)

nCipher nShield F3 Hardware Security Module – Wikimedia Commons (Photo: Alexander Klink, CC BY 3.0)

Googleplex HQ – Wikimedia Commons (Photo: Asoundd, CC BY-SA 4.0)

Key Sources and References

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf