openssl_pkey_new(): Private key length must be at least 384 bits, configured to 0

[101Admin]

When running the php artisan webpush:vapid command i get the following error:

   ErrorException 

  openssl_pkey_new(): Private key length must be at least 384 bits, configured to 0

  at vendor/web-token/jwt-library/Core/Util/ECKey.php:92
     88▕     {
     89▕         if (! extension_loaded('openssl')) {
     90▕             throw new RuntimeException('Please install the OpenSSL extension');
     91▕         }
  ➜  92▕         $key = openssl_pkey_new([
     93▕             'curve_name' => self::getOpensslCurveName($curve),
     94▕             'private_key_type' => OPENSSL_KEYTYPE_EC,
     95▕         ]);
     96▕         if ($key === false) {

      +18 vendor frames 

  19  artisan:13
      Illuminate\Foundation\Application::handleCommand(Object(Symfony\Component\Console\Input\ArgvInput))

I am using the latest version of the package:

"laravel-notification-channels/webpush": "^10.2",

I am running the latest version of OpenSSl:

OpenSSL 3.5.1 1 Jul 2025 (Library: OpenSSL 3.5.1 1 Jul 2025)
built on: Tue Jul  1 11:52:08 2025 UTC
platform: darwin64-arm64-cc
options:  bn(64,64)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
OPENSSLDIR: "/opt/homebrew/etc/openssl@3"
ENGINESDIR: "/opt/homebrew/Cellar/openssl@3/3.5.1/lib/engines-3"
MODULESDIR: "/opt/homebrew/Cellar/openssl@3/3.5.1/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_armcap=0x987d

And running php version 8.4:

PHP 8.4.10 (cli) (built: Jul  4 2025 00:25:55) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.10, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.10, Copyright (c), by Zend Technologies

[joostdebruijn]

Hi @101Admin! Which version of the package are you using?

[101Admin]

@joostdebruijn I am using

"laravel-notification-channels/webpush": "^10.2",

[joostdebruijn]

I'm not able to reproduce this issue. In fact, this isn't an issue in this package, but in a (nested) dependency: web-token/jwt-framework. However, there are other issues with this issue as well: web-token/jwt-framework#611. The author of that package seems to be unable to reproduce this either.

Maybe we can do some troubleshooting:

• Maybe you are using web-token/jwt-framework as a dependency on your project as well. Please make sure it has been updated to the latest version (v4), as web-push-php supports both v3.3 and v4.
• Can you please verify with which version of OpenSSL PHP has been built? This is not necessarily the same version of OpenSSL running on the system. And can you verify the output of openssl_get_curve_names() to check if prime256v1 is available?
• You should be able to isolate this issue down to the web-token/jwt-framework dependency by using the code sample in the previously mentioned ticket. Can you confirm that the issue persists when isolating it?

[101Admin]

Hey @joostdebruijn

I do not use web-token/jwt-framework in my project. Just for assurance I checked what version of it is installed in composer.lock file and it does say that i have version 4.0.4 installed.

This is the version of openssl in PHP i get when i dump php -i | grep -i "openssl":

openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 3.5.1 1 Jul 2025
OpenSSL Header Version => OpenSSL 3.5.1 1 Jul 2025
Openssl default config => /etc/ssl/openssl.cnf
openssl.cafile => /Users/user/Library/Application Support/Herd/config/php/cacert.pem => /Users/user/Library/Application Support/Herd/config/php/cacert.pem
openssl.capath => no value => no value
OpenSSL support => enabled

Yes I do receive prime256v1 in openssl_get_curve_names() when i dump it too.

I have tried to create the key on my own by using the openssl_pkey_new() function. I was able to create a key when i specify private_key_bits:

        $key = openssl_pkey_new([
            "private_key_type" => OPENSSL_KEYTYPE_EC,
            "private_key_bits" => 400,
            "curve_name" => "prime256v1"
        ]);

        dd($key);

But when i remove the private_key_bits property or if the value of this property is lower than 384, I get the exception.

I also don't think this problem is related to my project since I get the same error in a fresh laravel project.

This is indeed very confusing.

Do you also happen to use Laravel Herd? Since It comes with it's own openssl config. This is how my /etc/ssl/openssl.cnf looks like:

[ req ]
#default_bits		= 2048
#default_md		= sha256
#default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes

[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_min			= 2
countryName_max			= 2
stateOrProvinceName		= State or Province Name (full name)
localityName			= Locality Name (eg, city)
0.organizationName		= Organization Name (eg, company)
organizationalUnitName		= Organizational Unit Name (eg, section)
commonName			= Common Name (eg, fully qualified host name)
commonName_max			= 64
emailAddress			= Email Address
emailAddress_max		= 64

[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20

Could you maybe check if this is the same as your config. I think the commented default_bits property might be the issue here. Since this is a readonly file I cant change this property to test it.

[101Admin]

@joostdebruijn An Update: I was able to sudo update the openssl.cnf file and uncomment the default_bits property and the php artisan webpush:vapid command finally works 🎊 .

I still don't know why this was commented out and whether it's wise to uncomment it. Do you have any ideas as to why this is the case?

[joostdebruijn]

Thanks, @101Admin! I can reproduce it by uncommenting the line default_bits in my openssl config (which is enabled by default Ubuntu 24.04).

I still don't know why this was commented out and whether it's wise to uncomment it. Do you have any ideas as to why this is the case?

I don't know why they commented it out in Herd. Maybe we can file an issue over there to enable it by default. I don't think it's an issue, 2048 is currently considered as a safe default for RSA-keys. However, we're generating EC-keys here and then a value of 2048 doesn't make any sense as of today as we use the curves P-256 and P-384 in general.

Looking at the PHP source code over here it can be seen that openssl_pkey_new calls php_openssl_generate_private_key (see here), which checks the value of private_key_bits regardless of the key type and returns the posted error if the size is less than MIN_KEY_LENGTH, which is defined as 384. When generating the key we don't supply a value for private_key_bits at all. And if the key size is not specified with private_key_bits, it is initialized with a default value from the OpenSSL configuration file. In your OpenSSL configuration file the value is not set, and thus it's using the value 0 which is less than the required 384 minimum set in MIN_KEY_LENGTH.

As you can see, the php_openssl_generate_private_key function doesn't use the value of private_key_bits at all for generating an EC private key. So, the initial check on MIN_KEY_LENGTH should be skipped when a valid EC-curve is requested to generate a private key. Also, a MIN_KEY_LENGTH of 384 for RSA-keys is not safe by todays standards, so that value should be raised as well in my opinion. I see those lines are already for many years unchanged in the codebase of PHP, so I assume this code was never intended for EC-cryptography at all.

Long story short: it doesn't have anything to do with this package. I think it's mostly a bug in PHP in the first place and a wrong default configuration in Herd in the second place. I think the best solution for now is to adjust the OpenSSL-configuration in Herd and maybe file an issue there to set a sensible default there. A longer shot would be to fix this in PHP itself. I'll have a look at that next week.

For now I'm closing this issue here.