'One-off Human And Script Error', Says eMudhra Co-founder Kaushik Srinivasan As Company To Exit Global SSL/TLS Business | Exclusive

eMudhra has decided to withdraw from the global SSL/TLS certificate business following a security incident in which weak cryptographic keys associated with eight intermediate certificate authorities were found to be recoverable. The company’s board announced the decision on October 22, saying the business contributed around 1% of its global revenue and had become increasingly complex and costly to operate.

The decision comes as questions remain about how the weak keys were generated, why the problem went undetected for around 18 months, and whether the company’s existing checks were sufficient to identify the failure.

In an interview with Debashis Sarkar of News18, eMudhra co-founder Kaushik Srinivasan described the incident as a ‘one-off human

and script error’ that occurred during a key-generation ceremony on April 30, 2025. He acknowledged that the process had not been adequately checked and that an earlier error involving certificate revocation lists in May 2025 should have prompted a closer investigation.

“It’s a human and script error in a one-off incident, basically on a bad day,” Srinivasan said, adding that the company had been conducting such operations for a long time.

However, the incident was serious enough to prompt browser operators to distrust the affected certificate authorities. India’s Computer Emergency Response Team (CERT-In) also issued an advisory describing the cryptographic weakness.

In its October 22 announcement, eMudhra said the decision to exit the business followed detailed deliberations by its board. Chairman V. Srinivasan cited rising data-sovereignty and compliance requirements, increasing operational costs, and competition from providers offering SSL/TLS certificates free of charge.

The company also said the social media attention surrounding the incident had brought scrutiny disproportionate to the business’s contribution to overall revenue.

“For many certifying authorities, SSL/TLS is the whole business. For eMudhra it is one part of a much broader digital solutions portfolio,” the chairman said in the announcement, adding that the company would sharpen its focus on enterprise solutions and trust services other than SSL/TLS.

What Went Wrong With eMudhra’s Certificate Keys?

Explaining the incident, Kaushik Srinivasan said the affected issuing certificate authorities were created as part of a process intended to support eMudhra’s global operations.

The team generally generated issuing CA keys by running a script. However, the process for global operations involved exporting the keys and performing additional steps known as wrapping and unwrapping, which encrypt and decrypt the keys.

“There was a script error as part of this whole wrap-and-unwrap process, and that’s where everything went wrong,” he said.

Srinivasan acknowledged that the process lacked adequate maker-checker controls, despite personnel being present during the ceremony.

“I think there was an oversight in the sense that the process was not adequately checked,” he said.

According to eMudhra, the error caused the process to generate weak keys alongside the original strong keys. The weak keys were subsequently published to browser root stores.

CERT-In said the affected P-384 private keys had values smaller than 256 and could be recovered almost instantly from their corresponding public keys. The problem was caused by the key-generation process rather than a flaw in the P-384 cryptographic algorithm itself.

The weakness mattered because someone who recovered an intermediate certificate authority’s private key could potentially use it to issue fraudulent certificates for websites they did not control. Such certificates could be used to impersonate legitimate websites and, under certain circumstances, facilitate attacks on encrypted communications.

Srinivasan described the resulting keys as predictable and small.

“It’s not necessarily a non-compliant key. It’s a key that got created which can be, you know, sort of reverse-engineered or whatever the term may be. It’s a number that is predictable, known and small,” he said.

He attributed the incident to a combination of human error and a script error during the ceremony.

Why Did The Problem Go Undetected For 18 Months?

One of the biggest unanswered questions is why the weakness was not identified until October 2026, despite the keys having been generated in April 2025. Asked why it took an outside researcher around 18 months to identify the problem, Srinivasan said he was unsure why it had gone undetected, noting that the company had processes for audits and disclosures.

He suggested that the absence of certificates issued under the eight affected authorities could be one reason the issue escaped attention, but did not provide a definitive explanation.

“Why it went undetected, I don’t know, because we do have to follow a process of getting it audited, disclosed, etc.,” he said.

The company’s earlier audit processes are now an important part of the questions surrounding the incident. The full root-cause report and independent review will be needed to establish how the weakness survived the checks in place at the time.

May 2025 CRL Error Was An Earlier Warning Sign

The interview also brought attention to an earlier problem involving certificate revocation lists (CRLs). In May 2025, eMudhra published CRLs for affected intermediates with invalid signatures. Mozilla’s public incident record documents the earlier signing problem and its subsequent resolution.

Srinivasan acknowledged that the team initially signed the CRLs using the original key configuration. When the signatures failed validation, the team signed them using the weak keys.

“What happened was that when the CRLs needed to be signed, the key-label identifiers were similar. We made a mistake then as well by signing the CRLs with the original key. Obviously, they did not validate, so it came back and we signed with the ’40 key’,” he said.

He acknowledged that the team should have followed a maker-checker process to investigate what had gone wrong.

“We should have followed a maker-checker process then as well to understand what went wrong,” he said.

Srinivasan described the CRL signing problem as a subsequent misstep and agreed that it was probably an early warning sign.

The episode raises questions about why the failed signatures did not lead to a more thorough investigation of the key-generation and signing processes. The complete incident report is expected to provide more information about what checks were performed and why they did not identify the underlying weakness.

eMudhra Says No End-Entity Certificates Were Issued

A key part of eMudhra’s defence is that the affected intermediate certificate authorities did not issue end-entity certificates.

Srinivasan said the company’s internal issuance records showed no certificates had been issued under the affected authorities. He also pointed to Certificate Transparency logs, which record publicly trusted TLS certificates.

“Our internal issuance records indicate nothing. We’ve not issued anything,” he said.

He added that browsers and researchers had confirmed that no certificates were issued to Certificate Transparency logs under the affected authorities.

However, the absence of logged end-entity certificates does not mean the private keys were cryptographically secure. The confirmed weakness meant that the private keys could be recovered, creating the potential for fraudulent certificate issuance.

Srinivasan said the company activated its incident response after learning about the problem, contacted browser operators and revoked the affected keys. Browser operators subsequently distrusted the affected issuers, while Mozilla took further precautionary action involving the root certificate.

The distinction is important: the public record confirms the weakness of the keys, but does not establish that they were actually used in an attack.

What About Sectigo’s Role?

The incident also raised questions about Sectigo, which cross-signed the affected certificates. Asked about Sectigo’s role, Srinivasan said he did not believe the company had a role in the underlying problem.

“I think, obviously, we did something wrong. Because of the lapse, we should obviously have corrected it, but I don’t think they necessarily have a role as such,” he said.

The public technical findings identify the weak-key generation process as the central failure. Sectigo’s involvement in cross-signing is relevant to how the affected certificates were handled within the wider trust ecosystem, but it does not by itself establish that Sectigo caused the weakness.

eMudhra To Exit Global SSL/TLS Business

In its October 22 announcement, eMudhra said the global SSL/TLS business accounts for around 1% of its global revenue. The company cited rising compliance requirements, data-sovereignty obligations, operational complexity and costs as reasons for reconsidering the business.

It also said the availability of free SSL/TLS certificates from some large providers had reduced the commercial potential and return on investment of the business.

The company acknowledged the reputational impact of the incident but said the social media attention had brought scrutiny disproportionate to the business’s contribution to its overall revenue.

Asked about the risk to eMudhra’s reputation, Srinivasan said the company was still assessing the short-term impact.

“The reputational risk is obviously there. That risk has been caused by this incident, which is what we are trying to address,” he said.

He said the company planned to introduce additional safeguards, strengthen maker-checker controls and potentially use AI-assisted checks.

“For us, it’s more like ‘once bitten, twice shy’. We will put adequate safeguards and controls in place the next time we do this, supported by auditor assertions,” he said.

The board has now decided to leave the global SSL/TLS certificate business and focus on other digital trust and enterprise services.

What Happens To Existing Customers?

eMudhra said its G1 RSA roots would continue serving customers until the transition was complete. The company will work with browser programmes and customers to facilitate the move to alternative certificates.

It has also promised to replace affected customers’ certificates free of charge through partners. Certificate revocation and certificate-status services will continue until every issued certificate has expired or been replaced.

Srinivasan said eMudhra was working with affected customers, including a customer in North America with approximately 30,000 impacted certificates.

“We are working with them to transition them to our G1 root, which continues to operate,” he said.

He added that customers using the G1 root in the US and India were also being contacted to discuss their options.

“Essentially, the team is on a war footing,” he said.

The company has not provided a definitive date for completing the transition. It has said it will fulfil its remaining commitments to browser root programmes, including publishing a full root-cause report.

Are Indian Digital Signature And eSign Services Affected?

eMudhra maintains that its Indian digital signature certificate (DSC) and eSign services are separate from the affected global SSL/TLS infrastructure.

“The Indian DSC and eSign businesses are totally unrelated. They are not affected. They operate on completely isolated and separate infrastructure,” Srinivasan said.

He also said customers using the company’s certificates for other use cases under the Indian DSC business were not affected.

According to Srinivasan, the Ministry of Electronics and Information Technology (MeitY) had sent the company a list of questions and representatives had visited its premises.

“We’ve answered all those questions. That’s why they came up with a statement. There are additional questions, which we will also respond to in due course,” he said.

The company said its global and Indian digital signature certificate and eSign services, enterprise public key infrastructure platforms, emSigner electronic signature suite, and other digital trust services would continue operating normally.

Full Incident Report Still Pending

Srinivasan said eMudhra was preparing a full incident report and would publish the findings once they were ready. The company also plans an independent review of its remaining cryptographic infrastructure.

“We are looking for the right auditor who can support us with that initiative,” he said, adding that the report would be published on the company’s website for public review.

Asked whether the company had scanned all its other keys, Srinivasan said it had checked the other roots and issuers and that third parties and browsers had not found another problem. He said eMudhra would also conduct an independent review to establish credibility.

The October 22 announcement confirmed that a full root-cause report remained among the company’s outstanding commitments to browser root programmes. However, no specific publication date was provided. The exit decision addresses the future of eMudhra’s global SSL/TLS certificate business, but it does not resolve all the questions about the incident itself.

The key questions remain: why did the key-generation process produce predictable private keys, why did the maker-checker process fail, why did the May 2025 CRL signing error not prompt a deeper investigation, and how did the weakness remain undetected for around 18 months?

Srinivasan has promised full transparency. Until the root-cause report and independent review are published, the public record establishes a serious cryptographic failure but does not establish that the affected keys were used in an attack.

For eMudhra, the immediate priority is to transition customers and complete its commitments to browser programmes. For the wider internet security community, the incident highlights the importance of robust key-generation controls and the need for certificate authorities to investigate operational warning signs before they become larger security failures.