Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error:25066067:DSO support routines:dlfcn_load:could not load the shared library #43132

Closed
laneme opened this issue May 17, 2022 · 6 comments
Closed

Comments

@laneme
Copy link

laneme commented May 17, 2022

Version

16.15.0

Platform

Linux usernam 5.15.0-30-generic #31-Ubuntu SMP Thu May 5 10:00:34 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Very unfornutalely i cannot find a way to reproduce this accross platforms but its worth noting that this problem isnt specific to version 16.15.0. It happens on 16.10.0 and 18.* too

The following code is what triggers the error

var crypto = require('crypto')
var sign = crypto.createSign('RSA-SHA256')
sign.update(some_buffer)
sign.sign(some_private_key)

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

It DOES throw on the machine with OpenSSL 3.0.2, it does NOT throw on the OpenSSL 1.1.1f machine.

What is the expected behavior?

Expecting a signed buffer returned from crypto.sign funciton.

What do you see instead?

node:internal/crypto/sig:131
  const ret = this[kHandle].sign(data, format, type, passphrase, rsaPadding,
                            ^

Error: error:25066067:DSO support routines:dlfcn_load:could not load the shared library
    at Sign.sign (node:internal/crypto/sig:131:29)
    at Object.<anonymous> (/mytestfile.js:4:8)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47 {
  opensslErrorStack: [
    'error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib',
    'error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error',
    'error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header',
    'error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long',
    'error:0E076071:configuration file routines:module_run:unknown module name',
    'error:0E07506E:configuration file routines:module_load_dso:error loading dso',
    'error:25070067:DSO support routines:DSO_load:could not load the shared library'
  ],
  library: 'DSO support routines',
  function: 'dlfcn_load',
  reason: 'could not load the shared library',
  code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
}

Additional information

No response

@nemesisridiculii
Copy link

I'm getting the same error while using the Google Cloud Storage client library. When it goes to sign data to request an access token, it throws that error. I can also reproduce using the steps @laneme listed above.

As a workaround, I ran export OPENSSL_CONF=/dev/null before starting node. This prevents the issue and the code begins to work, however this also bypasses the config for openssl.

I first ran into this issue after upgrading to Ubuntu 22.04 which has the same uname -a as @laneme originally reported as their platform. This also has OpenSSL 3.0.2.

@bnoordhuis
Copy link
Member

There's almost certainly something in your openssl configs that instruct it to load a third-party library ("engine" in openssl nomenclature) that's missing or, more likely, incompatible with openssl 3.

@nemesisridiculii
Copy link

Because this seems like a configuration issue with Ubuntu, I posted this same question on askubuntu.com here: https://askubuntu.com/questions/1409458/openssl-config-cuases-error-in-node-js-crypto-how-should-the-config-be-updated

@k0d3d
Copy link

k0d3d commented May 19, 2022

Hi Guys,
I found a workaround while facing this issue using firebase-admin.
Hence, we suggest you to comment out the lines providers = provider_sectin the file/etc/ssl/openssl.cnf` and restart application once.

I took it off https://help.zoho.com/portal/en/community/topic/cant-install-zoho-workdrive-app-in-ubuntu-22-04

@nemesisridiculii
Copy link

Thanks @k0d3d. That's an interesting fix. If I'm understanding the config file correctly (which seems unlikely as I'm not an openssl guru) commenting out that line should mean that openssl loads the default provider and no others. (see man 7 OSSL_PROVIDER-default). This makes sense, however looking through the config, I don't see where any other providers are loaded anyway. I tried un-commenting the line activate = 1 in [default_sect] which didn't work. I also tried commenting out the line default = default_sect in [provider_sect] again with no luck.

Somehow it seems like if the config file defines any provider section (even if it does not define any providers) then it does not load the default provider, even if explicitly told to do so. Perhaps the default provider is complied in statically and cannot be loaded dynamically? Perhaps a bug in the openssl config routines?

Looks like providers are a new concept in openssl 3.0, so hopefully Ubuntu will provide an appropriate config soon. openssl/openssl#16249. In the meantime, I guess we now have two viable workarounds.

@bnoordhuis
Copy link
Member

As this isn't a bug in node I'll go ahead and convert the issue to a discussion.

@nodejs nodejs locked and limited conversation to collaborators May 23, 2022
@bnoordhuis bnoordhuis converted this issue into discussion #43184 May 23, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants