I’m trying to install and test BunkerWeb, but I’m not getting very far. I can’t access the setup wizard, because nginx is not running. The error message in the nginx logs says “SSL routines::passed invalid argument:group ‘X25519’ cannot be set”. I believe this is because X25519 is not supported by our FIPS-compliant OpenSSL install, and the solution is simply to edit the nginx config to remove it from the ssl_ecdh_curve directive. Except:
- Changes to /etc/nginx/default-server-http.conf are automatically overwritten, as explained by the documentation.
- Adding “SSL_ECDH_CURVE=prime256v1:secp384r1” to /etc/bunkerweb/variables.env has no effect.
- Adding “SSL_ECDH_CURVE=prime256v1:secp384r1” to a new .conf file in /etc/bunkerweb/configs/default-server-http similarly has no effect.
- I also tried using nginx config syntax (“ssl_ecdh_curve prime256v1:secp384r1”) in the latter file.
I restarted the bunkerweb and bunkerweb-scheduler services after attempting the config changes.
Am I even on the right track here? Am I just missing something simple? Thanks!
Hi,
You are right, and this one is on our side.
The issue comes from the default value:
SSL_ECDH_CURVE=auto
On a FIPS-enabled OpenSSL build, BunkerWeb’s curve auto-detection can return an empty result. When that happens, it falls back to our built-in curve list, which still includes X25519. Since X25519 is rejected by your FIPS OpenSSL build, NGINX fails to start and the setup wizard never gets a chance to load.
For now, the workaround is to set the curves explicitly so the auto-detection path is skipped.
In /etc/bunkerweb/variables.env, add or update:
SSL_ECDH_CURVE=prime256v1:secp384r1
Then restart the scheduler and check that the generated NGINX configuration uses the expected value:
sudo systemctl restart bunkerweb-scheduler
grep ssl_ecdh_curve /etc/nginx/default-server-http.conf
You should see:
ssl_ecdh_curve prime256v1:secp384r1;
and not X25519.
Using a custom .conf file is not a safe workaround here because BunkerWeb already renders an ssl_ecdh_curve directive in that context. Adding a second one would cause a duplicate directive error. Editing files directly under /etc/nginx/ would also be temporary, since they are regenerated by the scheduler.
We will fix the auto-detection so it only uses curves supported by the OpenSSL build running on the host. That way, FIPS systems will get a valid curve list automatically and will not need this manual override.
Thank you, I appreciate the response! However this solution was only successful up to a point. If I edit variables.env and then restart bunkerweb-scheduler while the bunkerweb core service is stopped, then yes, I do see default-server-http.conf regenerated without the “X25519”. However as soon as I do systemctl start bunkerweb, the nginx conf files are again overwritten, with the “X25519” value restored. The bunkerweb service fails to start, logging a familiar error:
SSL_CTX_set1_curves_list(“X25519:prime256v1:secp384r1”) failed (SSL: error:0A080106:SSL routines::passed invalid argument:group ‘X25519’ cannot be set)
It then gets stuck in an auto-restart loop, rewriting the incorrect value to the configs and then failing to start each time. Restarting bunkerweb-scheduler at this point has no effect (or at least, its changes get immediately reverted). I need to issue a systemctl stop bunkerweb to break the loop.
Do I need to clear out some cached settings somewhere or something before attempting to start the bunkerweb service? Or should I be bringing the services up in a different order? Any assistance on this would be greatly appreciated.
Hi, can you try again with the 1.6.12~rc2 version and confirm that it works for you ? Thank you! (keep in mind that this is a release candidate so make backups/snapshots first)
Hi, following up on this one.
The fix is in stable now, 1.6.12, so you don’t need to run a release candidate for it. Current stable is 1.6.13.
I also owe you an answer on your second point, which I skipped at the time. The config files being rewritten as soon as you systemctl start bunkerweb is intended behaviour: the database is the source of truth and everything under the nginx prefix is generated output, so hand edits there won’t survive a start. What changed is what gets written. The curve is now resolved by probing your actual OpenSSL build rather than falling back to a built-in list that still had X25519 in it, so a regeneration on a FIPS host shouldn’t put back a curve your OpenSSL will reject.
Snapshot first out of habit, but this should be a clean upgrade for you. I’d genuinely like to know how it lands. FIPS enabled OpenSSL isn’t something we can fully reproduce in house, so your confirmation is what closes this one out.
Regards,
Théophile
Thank you for the follow-up! Unfortunately we ended up going with a different WAF solution in the end, but I’m sure this will be helpful to others in the same boat. I am still kind of curious to see if this resolves it, though, so if I get a bit of free time in a dev environment at some point I may take another crack at it and report back.