What can OpenSSL learn from the eMudhra and PHP vulnerabilities?

At the November meeting of the OpenSSL Foundation Advisory Committee (FAC), we discussed two high-profile vulnerabilities:

1. A public key infrastructure (PKI) company, eMudhra, used 4 as a private key for one of its intermediate certificates. Anyone who figured that out could issue their own certificates for any site. To make matters worse, eMudhra also used 56, 66, 115, 155, 156, 230, and 237. Technically these are numbers between 1 and 2³⁸⁴ but these small numbers are easier to guess than numbers taken from the whole range. In fact a researcher did discover these private keys and reported the problem to organizations that maintain popular browsers. (See Scott Helme’s detailed post and the official incident report for more information.)
   
   
2. PHP released fixes for vulnerabilities that could allow attackers to run code on remote servers. A security audit turned up memory problems in 2024, but the fix was not published until Oct 21, 2026. Together the vulnerabilities have been labeled PHP2Shell.

Our conversation focused on what lessons the OpenSSL Project could take from these incidents.

The eMudhra compromised certificates

Certificate Authorities (CAs), such as eMudhra, sign and issue digital certificates. One tool they could use is the OpenSSL Library, which even includes a sample minimal CA application. Browsers, such as Chrome and Firefox, have systems to send out lists of revoked certificates. But the OpenSSL Library does not maintain a database of certificates. Instead systems depend on a third party database, such as the ca-certificates package on most Linux distributions.

Back in July, Dmitry Belyavskiy, who represents the distributions community on the FAC, started a discussion about integrating the upki project with OpenSSL:

UPKI implements platform-independent browser-grade certificate infrastructure.

The first goal of this project is to provide reliable, privacy-preserving and efficient certificate revocation building on foundational work by Mozilla.

Now that we’ve seen a clear case when this could be useful, there have been two votes in the OpenSSL Communities:

1. OpenSSL integration with UPKI initiated by Dmitry in the Distributions community and
2. Better revocation in TLS proposed by Clemens Lang, who is also a FAC member, in the Large Business community.

The second vote also asked about enabling Certificate Transparency (CT) by default. The OpenSSL Library supports CT, but ships with an empty configuration file. If OpenSSL included a valid configuration, it would mitigate problems such as the weak private keys by allowing compromised certificates to be efficiently revoked. 

On the call, Randall Becker, who is the community maintainer for the NonStop port of OpenSSL, pointed out that some supported operating systems can’t currently use UPKI because it’s written in Rust. The discussion turned to potential workarounds or using a simpler system as a backup option. But as Matt Caswell, the Foundation’s executive director, pointed out, the next step should be to have a better certificate revocation story and consider implementation details in other contexts.

We encourage you to be part of the conversation on the OpenSSL Communities platform.

PHP2shell

It might be surprising to discover that 69% of websites use PHP as their server-side programming language. Matt  described PHP2Shell as PHP’s Heartbleed moment. Fortunately, PHP has a Foundation that funds a team of core developers, which includes Jakub Zelenka, who is also contracted with the OpenSSL Foundation to build out our test suite. 

Like any long-running project, PHP supports all sorts of legacy code. Clemens looked over the patches and noted how technical debt complicated fixing the vulnerabilities. Technical debt can be easier to identify than to fix. As Matt pointed out, we’ve known about potential side-channel attacks in our BIGNUM implementation for years, but it took an investment from the Sovereign Tech Fund to actually get a fix for it.

Nicola Tuveri, a representative from the Academic community, suggested the Foundation include technical debt work in our fundraising appeals. Removing outdated code and refactoring aren’t the most exciting projects, of course. On the other hand, that sort of work improves the security of the Library and makes future improvements easier to complete. An important feature of OpenSSL 4.0 was removing ENGINEs which eliminated thousands of lines of code.

Learning from vulnerabilities in other projects helps us fulfill our mission to provide “access to security and privacy tools”.

Photo by SHAN LU on Unsplash