Redirect to HTTPS not available in HPE 1920-24G (JG924A) and seems to be missing encryption keys

I have set up Redirect to HTTPS on two HPE 1920-24G (JG924A) devices, but neither seems to be working. I can access the device via http but no https:

root@at-a-different-device:~# curl https://xxx.xxx.xxx.xxx        
curl: (7) Failed to connect to xxx.xxx.xxx.xxx port 443 after 0 ms: Connection refused

root@at-a-different-device:~# curl http://xxx.xxx.xxx.xxx
<!DOCTYPE html>
<html>
        ...
</html>

Here is my uttpd setup:

root@OpenWrt:~# cat /etc/config/uhttpd

config uhttpd 'main'
    list listen_http '0.0.0.0:80'
    list listen_http '[::]:80'
    list listen_https '0.0.0.0:443'
    list listen_https '[::]:443'
    option redirect_https '1'
    option home '/www'
    option rfc1918_filter '1'
    option max_requests '3'
    option max_connections '100'
    option cert '/etc/uhttpd.crt'
    option key '/etc/uhttpd.key'
    option cgi_prefix '/cgi-bin'
    list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
    option script_timeout '60'
    option network_timeout '30'
    option http_keepalive '20'
    option tcp_keepalive '1'
    option ubus_prefix '/ubus'

config cert 'defaults'
    option days '397'
    option key_type 'ec'
    option bits '2048'
    option ec_curve 'P-256'
    option country 'ZZ'
    option state 'Somewhere'
    option location 'Unknown'
    option commonname 'OpenWrt'

Here is my system board info:

root@OpenWrt:~# ubus call system board
{
    "kernel": "6.6.119",
    "hostname": "OpenWrt",
    "system": "RTL8382",
    "model": "HPE 1920-24G (JG924A)",
    "board_name": "hpe,1920-24g",
    "rootfs_type": "squashfs",
    "release": {
        "distribution": "OpenWrt",
        "version": "24.10.5",
        "revision": "r29087-d9c5716d1d",
        "target": "realtek/rtl838x",
        "description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
        "builddate": "1766005702"
    }
}

After some research online, I checked for the encryption keys and they seem to be missing. Running this command on a different device for which the Redirect to HTTPS is working yields keys:

root@OpenWrt:~# ls -lah /etc/uhttp*
-rw-r--r--    1 root     root         664 Oct 24  2021 /etc/uhttpd.crt
-rw-r--r--    1 root     root         121 Oct 24  2021 /etc/uhttpd.key

But running this on both devices where Redirect to HTTPS is not working does not list any keys:

root@OpenWrt:~# ls -lah /etc/uhttp*
ls: /etc/uhttp*: No such file or directory

I have only run UCI commands on the device, so I don't think I would have deleted the keys, but I may have done something to stop them from being generated.

This OpenWrt image was created using the Customize installed packages and/or first boot script in the OpenWrt Firmware Selector. I added a uci-defaults script to run on first boot but did not add or delete any packages for the build. The uci-defaults script changes the lan interface to be a dhcp client and also the vlan id to match that for the network its on. All other functionality appears to be working fine.

Is this a bug or something I’ve done?

How do I remedy and will I need to reapply after an upgrade?

Try installing luci-ssl and test. If successful, append it to the package list on the webpage and build a new image. I surmise that default list in the Firmware Selector may differ from the built image (assuming the default image even has it).

1 Like

You beat me too it.

I downloaded the standard image from the OpenWrt Firmware Selector and installed it. The Redirect to HTTPS works fine.

I downloaded an OpenWrt image was created using the Customize installed packages and/or first boot script in the OpenWrt Firmware Selector without any modifications and the Redirect to HTTPS fails.

It’s disappointing that the Customized OpenWrt Firmware Selector and the standard build package lists are different. I will not trust going forward.

I’ll give the luci-ssl package a try later.

1 Like

Confirming that installing luci-ssl fixed the problem.

Thank you for your help.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.