[BUG] ssl certificate failed

[oliverbienert]

What happened?

Hello,
I've successfully set up a reverse proxy configuration on a local Ubuntu 24.04 instance running in a lxd container:

DNS_RESOLVERS=8.8.8.8 8.8.4.4
HTTP_PORT=80
HTTPS_PORT=443
API_LISTEN_IP=127.0.0.1
SERVER_NAME=portal2.lxd
USE_BAD_BEHAVIOR=no
USE_CUSTOM_SSL=yes
CUSTOM_SSL_CERT=/opt/.certs/portal2.lxd.pem
CUSTOM_SSL_KEY=/opt/.certs/portal2.lxd-key.pem
USE_MODSECURITY=no
USE_REVERSE_PROXY=yes
REVERSE_PROXY_HOST=http://unix:/run/gunicorn.sock

Then I tried the same setup on a virtual machine (HyperV, Ubuntu 24.04) in my local institute LAN, replacing servername pathes to certificate files and DNS resolver addresses (I have replaced the first two parts of the relevant IP-Addresses with xxx.xxx):

SERVER_NAME=xxx.xxx.100.82
CUSTOM_SSL_CERT=/opt/.certs/xxx.xxx.100.82.pem
CUSTOM_SSL_KEY=/opt/.certs/xxx.xxx.100.82-key.pem

The certificates were created using mkcert on my local dev system (Also Ubuntu 24.04).

However, when I run the configuration; I get the errors as shown in log output

The certificates were working properly on this machine before installing bunkerweb, meaning, I had a working nginx configuration:

    listen  443 ssl;
    server_name  xxx.xxx.100.82;
    ssl_certificate     /opt/.certs/xxx.xxx.100.82.lxd.pem;
    ssl_certificate_key /opt/.certs/xxx.xxx.100.82.lxd-key.pem;

Can someone help me out here? Is this, because I am using an IP-address in the second machine?

How to reproduce?

As described in 'What happened', I use identical setups on a lxd instance and a virtual machine in HyperV. Only on one machine I can reproduce the error.

Configuration file(s) (yaml or .env)

DNS_RESOLVERS=xxx.xxx.100.11
HTTP_PORT=80
HTTPS_PORT=443
API_LISTEN_IP=127.0.0.1
SERVER_NAME=xxx.xxx.100.82
USE_BAD_BEHAVIOR=no
USE_CUSTOM_SSL=yes
CUSTOM_SSL_CERT=/opt/.certs/xxx.xxx.100.82.pem
CUSTOM_SSL_KEY=/opt/.certs/xxx.xxx.100.82-key.pem
USE_MODSECURITY=no
USE_REVERSE_PROXY=yes
REVERSE_PROXY_HOST=http://unix:/run/gunicorn.sock

Relevant log output

2024/08/16 13:51:36 [error] 12134#12134: *97 [SSL-CERTIFICATE] customcert:ssl_certificate() failed : /usr/share/bunkerweb/core/customcert/customcert.lua:96: attempt to concatenate local 'err' (a nil value), context: ssl_certificate_by_lua*, client: xxx.xxx.103.143, server: 0.0.0.0:443
2024/08/16 13:51:36 [error] 12134#12134: *97 [SSL-CERTIFICATE] letsencrypt:ssl_certificate() failed : /usr/share/bunkerweb/core/letsencrypt/letsencrypt.lua:109: attempt to concatenate local 'err' (a nil value), context: ssl_certificate_by_lua*, client: xxx.xxx.103.143, server: 0.0.0.0:443
2024/08/16 13:51:36 [error] 12134#12134: *97 [SSL-CERTIFICATE] selfsigned:ssl_certificate() failed : /usr/share/bunkerweb/core/selfsigned/selfsigned.lua:96: attempt to concatenate local 'err' (a nil value), context: ssl_certificate_by_lua*, client: xxx.xxx.103.143, server: 0.0.0.0:443

BunkerWeb version

1.5.9

What integration are you using?

Linux

Linux distribution (if applicable)

Ubuntu 24.04

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[fl0ppy-d1sk]

Hello @oliverbienert,

Can you double check that nginx user can access both certificate and key ?

[oliverbienert]

Thank you for looking into that. Unfortunately, since August, I had a certain pressure to make progress so I removed bunkerweb from my stack. However, the certificates are still in use. I tested permissions with:

sudo -u nginx test -r /opt/.certs/xxx.xxx.100.82.pem; echo "$?"
0
sudo -u nginx test -r /opt/.certs/xxx.xxx.100.82-key.pem; echo "$?"
0

So that means nginx can read the files.
It may happen that I can give bunkerweb another try in a couple of days or so and I will come back here if so.

What confuses me are the messages in the error log above concerning letsencrypt and selfsigned certificates. As I haven't configured them at all made me believe the error has perhaps nothing to do with read rights.

[TheophileDiot]

Hi, starting to catch up on pending issues. Made a quick search and by the look of it it looks like its linked to a SNI issue where the server_name property returns a nil value: lua-resty-core/ssl.server_name

[TheophileDiot]

Okay as I understand it, it's due to the SERVER_NAME variable having a static ip instead of a domain name. Therefore the browser doesn't send an SNI name as it's not needed.
We'll add a fallback to it so that it uses the requested ip as the key to lookup for the cert in the datastore.

[oliverbienert]

Thank you. Does that mean that at the moment there is no such fallback?

[TheophileDiot]

Hi, sorry for the late response. Indeed as of now no fallback are implemented.