OpenSSL is one of the most popular tools for cryptography, widely used for securing communications over the internet. In March 2025, a new vulnerability — CVE-2025-4575 — was reported in OpenSSL 3.5. This bug involves the openssl x509 command line application and the use of the -addreject option. In short: if you tried to explicitly reject certain uses for a certificate, the software would instead mark them as trusted.

This post explains, in simple language, how the issue happens, what risks are involved, and how you can check if you’re affected. We include code snippets to help you reproduce or recognize the problem.

What Is the Issue? (Summary)

- Intended Feature: The OpenSSL x509 -addreject flag lets users specify particular certificate usages (like code signing or TLS authentication) that should be explicitly rejected for a given certificate stored in the trusted certificate format.
- The Bug: In OpenSSL 3.5, using -addreject doesn't do what it claims. Due to a copy-paste error in recent code refactoring, it instead adds a trusted use for the certificate.
- Impact: If you intended to *reject* a certificate for a particular use (e.g., CMS signature verification), the certificate ends up trusted for that use.

Rely on rejected usages for correct security behaviors.

Older/OpenSSL (<=3.4) versions and FIPS modules are not affected.

Who’s Affected?

- Only users using the "trusted certificate format" with the openssl x509 command line tool and trying to add rejected uses via -addreject.
- Most users, SSL/TLS servers, and FIPS modules are not affected.

The Typical Use

Let’s say you want to trust a CA certificate only for authenticating servers (TLS Web Server Authentication), but *deliberately* not for CMS (Cryptographic Message Syntax) signature verification.

Your expected command might look like

openssl x509 -in ca.crt -addext keyUsage=keyCertSign -addtrust serverAuth -addreject emailProtection -out trusted-ca.pem

You intend:

What Actually Happens (3.5 only)

Due to CVE-2025-4575, emailProtection is added as a trust, not a rejection. So the certificate will now be trusted for both serverAuth _and_ emailProtection — the opposite of what you wanted.

Here’s how you’d use it (vulnerable OpenSSL 3.5)

openssl x509 -in my-ca.pem \
  -addtrust serverAuth \
  -addreject emailProtection \
  -out trusted-ca.pem

Expected:
trusted-ca.pem is only trusted for serverAuth.

Reality (with CVE-2025-4575):
trusted-ca.pem is trusted for both serverAuth *and* emailProtection.

`bash

openssl req -new -x509 -days 365 -keyout ca.key -out ca.crt -subj "/CN=TEST CA" -nodes

`

You will find both serverAuth AND emailProtection listed under certificate trust, when emailProtection should've appeared as rejected.

Severity: LOW (only affects advanced users manipulating trusted certs with -addreject in 3.5).

- Security Implication: Intended rejections (usages you wanted to block) won’t be blocked; instead, certificates may get *more* trust than desired.

In complex PKI setups, this could broaden certificate powers in subtle ways.

## How to Fix / What to Do

- Upgrade OpenSSL: This has been or will be fixed in OpenSSL 3.5.x. Always check for the latest patched release!
- Workaround: You can manually edit trust settings or use an unaffected OpenSSL version (3.4 or below).
- Verify Trusted Certificates: Double-check trusted usages after running openssl x509 -addreject, using:

References

- OpenSSL Security Advisory for CVE-2025-4575 (Replace with actual security advisory once published)
- OpenSSL CLI Documentation
- OpenSSL Source Code (GitHub)
- OpenSSL Issues Tracker

Conclusion

CVE-2025-4575 is a classic example of a simple copy-and-paste coding error creating subtle and hard-to-spot security issues in widely-used tools. If you don’t use special trusted certificate formats or the -addreject flag, you’re not affected. But for those who do: check your trusted certs and ensure your trust/reject intentions actually match reality.

Best Practice:
After altering certificate trust settings, always review the result with openssl x509 -text. Don't wait for bugs to surface!


If you have more questions or want to contribute a fix, visit the OpenSSL GitHub repository or mailing list.


*Stay safe and always double-check your cryptographic assumptions!*

Timeline

Published on: 05/22/2025 14:16:07 UTC
Last modified on: 05/23/2025 15:55:02 UTC