Skip to content

crypto.X509Certificate.toLegacyObject doesn't propagate internal OpenSSL errors #63265

Closed as not planned

Description

@ndossche

Version

v25.9.0

Platform

Linux 749dbb0e74fd 6.8.0-106-generic #106-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar  6 07:58:08 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

crypto

What steps will reproduce the bug?

For context, consider this JavaScript code as an illustrative example:

const { X509Certificate } = require('crypto');
const fs = require('fs');
console.log((new X509Certificate(fs.readFileSync('test/fixtures/x509-escaping/alt-28-cert.pem'))).toLegacyObject());

Various values are fetched from a certificate to put into an object here:

MaybeLocal<Value> values[] = {
GetX509NameObject(env, cert.getSubjectName()),
GetX509NameObject(env, cert.getIssuerName()),
GetSubjectAltNameString(env, cert),
GetInfoAccessString(env, cert),
Boolean::New(env->isolate(), cert.isCA()),
Undefined(env->isolate()), // modulus
Undefined(env->isolate()), // exponent
Undefined(env->isolate()), // pubkey
Undefined(env->isolate()), // bits
GetValidFrom(env, cert),
GetValidTo(env, cert),
GetFingerprintDigest(env, Digest::SHA1, cert),
GetFingerprintDigest(env, Digest::SHA256, cert),
GetFingerprintDigest(env, Digest::SHA512, cert),
GetKeyUsage(env, cert),
GetSerialNumber(env, cert),
GetDer(env, cert),
Undefined(env->isolate()), // asn1curve
Undefined(env->isolate()), // nistcurve
};

Various of these functions can actually fail internally in OpenSSL, but this isn't propagated via an exception. So it is impossible to distinguish between a certificate that doesn't have a certain value or a failure.
For example, a failure somewhere in this code for example will cause the absence of the subjectaltname property of the returned object:

node/deps/ncrypto/ncrypto.cc

Lines 1086 to 1097 in 6009d93

BIOPointer X509View::getSubjectAltName() const {
ClearErrorOnReturn clearErrorOnReturn;
if (cert_ == nullptr) return {};
BIOPointer bio(BIO_new(BIO_s_mem()));
if (!bio) return {};
int index = X509_get_ext_by_NID(cert_, NID_subject_alt_name, -1);
if (index < 0 ||
!SafeX509SubjectAltNamePrint(bio, X509_get_ext(cert_, index))) {
return {};
}
return bio;
}

More specifically, our testing framework reported these concerns specifically for the following OpenSSL calls that can fail:

`OBJ_obj2nid` via `ncrypto::X509Name::Iterator::operator*[abi:cxx11]() const+0x5ad` with return value `0`
`BN_bn2hex` via `ncrypto::BignumPointer::toHex() const+0x58` with return value `0`
`ASN1_INTEGER_to_BN` via `ncrypto::X509View::getSerialNumber() const+0x180` with return value `0`
`BIO_new` via `ncrypto::X509View::getInfoAccess() const+0x14f` with return value `0`
`BIO_new` via `ncrypto::X509View::getValidFrom() const+0x14f` with return value `0`
`BIO_new` via `ncrypto::X509View::getSubjectAltName() const+0x14f` with return value `0`
`BIO_new` via `ncrypto::X509View::getValidTo() const+0x14f` with return value `0`
`X509_get_ext_by_NID` via `ncrypto::X509View::getInfoAccess() const+0x1bd` with return value `0`
`X509_get_ext_by_NID` via `ncrypto::X509View::getSubjectAltName() const+0x1bd` with return value `0`
`i2d_X509_bio` via `ncrypto::X509View::toDER() const+0x1c4` with return value `0`
`ASN1_TIME_print` via `ncrypto::X509View::getValidFrom() const+0x1cc`  with return value `0`
`ASN1_TIME_print` via `ncrypto::X509View::getValidTo() const+0x1cc`  with return value `0`

How often does it reproduce? Is there a required condition?

When an allocation failure happens or unspecified other type of failure happens inside OpenSSL, it will reproduce.

What is the expected behavior? Why is that the expected behavior?

I would expect an exception at least in the case of an internal OpenSSL failure.

What do you see instead?

The property will not be added to the object, making it impossible to detect whether a property is absent from the certificate or if there was an internal error in OpenSSL.

Additional information

Found by an experimental static-hybrid analyzer I'm working on.

Activity

  1. github-actions commented on Aug 21, 2026

    @github-actions
    Contributor

    This issue has been marked as stale due to 90 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  2. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Aug 21, 2026
  3. github-actions commented on Sep 21, 2026

    @github-actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions