Chances are you followed the whole eMudhra story, thought “if they managed it with security like that, surely I can too,” and clicked on this post.

Great! Congratulations on taking the first step. The road ahead involves a lot of reading (certificate policies, audit criteria, root program requirements, and legislation) before you can even begin.

Jokes aside, it’s a fair question. How does a random company end up in a position where its mistakes become everyone’s problem? Who approves that, and what does an applicant actually have to do?

And if it’s just a checklist, why aren’t there more of them? Here’s how many organizations each major root program trusts (via CCADB, as of October 2026):

ProgramRoot certificatesCA owners
Apple12239
Chrome10144
Microsoft18161
Mozilla11847

A few dozen organizations, trusted by essentially every device on the planet. That’s actually insane!

I went looking for a good writeup explaining how this all works and couldn’t find one, so I spent a few hours putting this together in case you’re curious too :)

But of course, if you want to be a Root CA, you’ll first need to know…

Why do we need a Root CA anyway?

When you opened kuber.studio to read this, just encryption can’t guarentee you’re actually directly talking to my server.

Man-in-the-middle attack: a perpetrator sits between the user and the web application, replacing their original connection with two new ones

Picture someone sitting between us, they generate their own encryption key and hand it to you, they read everything you send, then forward it to me. Everything’s “encrypted”, but all of our data is essentially leaked. That’s a man-in-the-middle attack, and it’s why TLS also has to authenticate the server, proving that the public key you received really belongs to the domain you meant to visit.

That proof is a digital certificate. which is issued by a certificate authority (CA) after checking that you actually control your domain. Your browser then checks the same and then follows the chain of trust back to a trust anchor: a root certificate it already has baked in.

(PS: this segment by ThePrimeagen has a great first principles explanation on this)

now that we know this, the obvious question remains.

Who decided these companies should be trusted?

Funnily enough, we never got a new arrangement for the internet, we inherited how it worked in the SSL era. The major browsers just started shipping trusted certificates with their software.

You can watch that informal arrangement harden into policy in Frank Hecker’s 2005 proposal for Mozilla’s CA policy. He suggested accepting CAs that passed a WebTrust or equivalent independent audit, while admitting an audit proves a CA follows its own policies, not that those policies are good enough to protect the internet.

By 2008, Mozilla had formalized a public process requiring independent evidence and published policies, charging no inclusion fee while reserving the right to reject or remove CAs. Of course funnily enough, applications are still filed on Mozilla’s bug portal and it became even more specific with the CA/Browser Forum’s TLS Baseline Requirements ; not including the other conditions other browsers have for the same.

You can probably see where this is going.

Okay but how do I ACTUALLY Start

First you gotta know that there’s levels to this.

If this is for your own servers or devices, great ! You can create a private CA and install its root on the devices you control.

If you want to issue legally recognised digital signatures, your country’s rules enter the picture. An Indian licence to sign tax filings, for example, doesn’t make Firefox trust you to authenticate websites.

But you want public browser trust. You’d like strangers’ computers to accept your signatures without anyone installing anything.

Ambitious. Let’s see your finances.

Get funding, then maybe a licence

Before anything else, you’ll want serious, long-term money. Major examples I cover here include Google’s own CA operation, Fastly’s Certainly, and Let’s Encrypt (a nonprofit whose founders raised corporate funding to pay for hardware and staff.) You don’t personally need to be a millionaire (it usually does help though,) but you’ll want to arrive with people willing to fund this for years.

Next, depending on where you are, the government most likely want a say, browsers don’t require a national licence (Let’s Encrypt never needed one), but some countries regulate anyone offering certificate services.

India, interestingly asks companies entering its regulated CA business for ₹50 crore in net worth (roughly $5.3 million) plus ₹5 crore in paid-up capital before you can even apply.

Here’s a few of these I compiled:

JurisdictionRelevant law or schemeWhat the local approval involves
IndiaInformation Technology Act 2000; IT (Certifying Authorities) Rules 2000; CCA licensing guidelinesA licence from the Controller of Certifying Authorities, with financial eligibility, an infrastructure assessment and an empanelled audit.
United StatesE-SIGN Act, 15 USC §7001Recognises electronic signatures, but creates no CA licence or browser-root process.
European UnioneIDAS, as amended by Regulation 2024/1183Qualified trust services need conformity assessment, national supervision and trusted-list status. It also places specific obligations on browsers for qualified website certificates.
United KingdomUK eIDAS framework; Electronic Identification and Trust Services Regulations 2016; ICO qualification processAn accredited body assesses you, then the ICO grants qualified status and trusted-list entry. Reassessment at least every 2 years.
ChinaElectronic Signature Law; electronic-certification service rulesPermission from MIIT plus cryptographic approval. The application guide asks for at least 30 relevant staff and RMB 30 million in registered capital.
SingaporeElectronic Transactions Act 2010; Certification Authority Regulations 2010; IMDA schemeVoluntary accreditation.
JapanAct on Electronic Signatures and Certification BusinessOptional accreditation for certification businesses that meet the statutory requirements.
BrazilProvisional Measure 2,200-2/2001; ICP-Brasil accreditationYou join a national hierarchy headed by ITI after documentary, financial and technical checks and a pre-operational audit.
AustraliaGatekeeper PKI FrameworkGovernment PKI accreditation, being retired on April 6, 2028.
United Arab EmiratesFederal Decree-Law 46/2021; TDRA trust-services licensingLicensing with conformity documentation and review. AED 10,000 to apply, then AED 12,000 per trust service or AED 15,000 per qualified one.

There’s varience to each process but in most places it’s:

before building the infrastructure, you present your business plan, expertise and proposed facilities to the authority. Once that clears, you build the setup; it must be ready before submitting the application. Then come document checks, an audit of the software and facilities, corrections, and approval.

That’s the formal way of saying, you need to have some skin in the game before for the regulators to even take your plan seriously and if you genuinely manage capital, it’s likely because you are largely operating through established digital-signature businesses or regulatory companies.

Hire a lot of people and generate the keys

Qualified? Congratulations! Now you need engineers, security and compliance staff, secure facilities, backups, and a lot of customer support.

Your private keys stay in a hardware security module (HSM) and surprisingly the hardware is probably the easiest part. The Baseline Requirements ask for FIPS 140 Level 3 or equivalent, and even something as small as a YubiHSM 2 comes in a validated version.

Generating a root key is a whole event too, there’s a formal key ceremony with designated participants, a scripted procedure, and an auditor either watching in person or reviewing a full video.

If you’re interested, here’s eMudhra’s last ceremony’s disclosure that got independently audited.

Then the issuance system. It has to validate domains, sign certificates, publish revocation information, and actually revoke things when needed. This is all documented in your Certificate Policy and Certification Practice Statement, then gets independently audited under WebTrust or ETSI standards.

”We’d be Delighted to Consider your Application”

Now you can finally apply! That goes through the Common CA Database (CCADB), which collects your certificates, policies, audits and ownership details.

Meeting the requirements should get you in, right?

Well, no. All root programs actually make their own decision.

Mozilla needs the hierarchy, key-generation evidence, audit reports and a compliance assessment and then the approval is their choice. So is Google and Apple.

Microsoft is not even accepting new CAs.

Microsoft's notice that it is not accepting new CAs

For a sense of the timeline, look at TrustAsia. It applied to Mozilla in January 2021, went back and forth with audit updates, key-generation evidence and revised assessments, and finally entered public discussion in July 2023. Approval came later that August, and its roots shipped in Firefox 121 later that year.

That’s almost 3 years, for a company already in the certificate business.

And then it did it ALL again. Its new dedicated TLS and email roots went through another public discussion in 2025 and a separate Chrome approval. Every new root plays the same waiting game.

You’re approved. What about everybody’s old phone?

Getting into devices is not easy either, when was the last time you updated your Alexa or TV’s CA list?

Let’s Encrypt generated its first root in June 2015 and issued its first certificate that September. It wasn’t directly trusted by all the major root programs until July 2018, and even then, plenty of older devices never really got the update.

The workaround is cross-signing: a CA that’s already trusted signs your CA’s key, so old clients can follow the chain back to a root they already know. Let’s Encrypt leaned on IdenTrust for this.

Let's Encrypt's 2015 hierarchy with IdenTrust cross-signatures

The catch is that you need an established CA willing to vouch for you. The other option is buying a root outright, as Google did with GlobalSign’s R2 and R4 in 2017, though a change of ownership still takes time to get reviewed by the root programs.

Let’s Encrypt looked into buying one too. Its founders reported quotes of $1–8 million depending on the root’s remaining lifetime, compatibility and baggage, and never went through with it.

What’s the business model here?

For commercial CAs, it’s selling certificates and managing them. TrustAsia, for example charges for issuance, renewal and related services and sells certificate-management products on top.

For platform companies, the payoff is indirect. Fastly built Certainly after other CAs’ incidents kept hitting its customers, bringing issuance in-house for reliability and support.

Let’s Encrypt is the nonprofit version of this, funded by sponsors, grants and donations to get HTTPS everywhere. Its operators reported spending roughly $3 million in 2018, not counting reserves or in-kind contributions, with about two-thirds going to staff.

So why aren’t there more of them?

By now you’ve seen why the number is so small. It takes capital, specialist staff, audits, years of waiting, and a reason for browsers to want another issuer. Most businesses are better off buying certificates from someone already trusted.

Browsers also rightfully have a good reason to be picky. Any trusted CA can issue a certificate for any domain.

Congratulations, You’ve Done it

Now the real job starts. You get audited every year, update your systems every time the rules change, and answer in public for any issue. Under the CCADB incident rules, you generally owe an initial report within 72 hours of finding out and a full report within 14 days of that.

Even leaving takes a lot of work, eMudhra’s exit announcement committed to keeping certificate-status services running until every certificate it issued had expired or been replaced, which would take years.

And this made me question the entire process

If it really was that easy to track all the applications, objections, audit statements and failures, even though they were scattered, I’m genuinely shocked we don’t have better ways to keep it all in check.

I’m even more shocked about the eMudhra incident passing all the independent audits, checks and reports even after being in the game for so long with those security casualties.

If you’ve seen me online or read my blogs, I’m very optimistic about the progress AI brings to society, especially in technology -- but seeing the infrastructure issues with such a “load bearing” (pun unintended) part of the internet, which is largely considered very hard to break into does make me think.

What Hecker admitted in 2005 is still true more than a decade later, an audit proves a CA follows its own policies, not that those policies are good enough. Perchance.