LuCi HTTPS not working after upgrade to 19.7.4

Installing and Using OpenWrt
#1

Hello!

I just recently upgrade to 19.7.1 to 19.7.4 and LuCi HTTPS stopped working. Thought that I may need to re-do the luci-ssl configuration I followed:

https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings

I used luci-ssl-openssl (instead of luci-ssl). I have also created a myconfig.conf file as per below:
image

which generated mycert2.crt and mycert2.key files in /etc/ssl/ folder and uploaded using Luci-uhttpd:

image
image573Ă—520 49.2 KB

Saved and Applied the changes then rebooted the router for good measure.

After all of this, HTTPS still not working :frowning:

Hope you guys can help me out :pray:

Sincerely,

Vince

1 Like
#2

Also just to further add, I tried to look at the syslog but didn't find anything relevant under UHTTPd :frowning:

#3

Is the server running?
ps wwww | grep uhttp
Is it bound to the proper addresses?
netstat -lnp | grep http

#4

Hello @trendy,

Thanks much for taking time to reply. Here’s the output for the commands you ask to run.

image
image2048Ă—599 151 KB

Sincerely,

Vince

#5

uhttpd is not listening to 192.168.1.2:443
Is there something else listening? netstat -lnp | grep 443

Please use the "Preformatted text </>" button for logs, scripts, configs and general console output.
grafik

1 Like
#6

Hi @trendy,

Alright, here’s the result netstat grep 443.

root@OpenWrt-1900:~# netstat -lnp | grep 443
tcp        0      0 :::443                  :::*                    LISTEN      1629/uhttpd
root@OpenWrt-1900:~#

Weird huh? ... in the luci uhttpd page 192.168.1.2 defined for https. :disappointed_relieved:

Thanks!

Vince

#7

Just making sure, but this router has 192.168.1.2 as it's normal LAN ipv4 address, right?

(So that 192.168.1.2 is not any specially invented address just for uhttpd...)

#8

Hi @hnyman

Yes ... it’s a dumb AP that’s why it is 192.168.1.2. The main router 192.168.1.1.

Haven’t upgraded the main WRT3200 router until things are stable with this. :disappointed_relieved:

Is there a way to put UHTTPD to debug mode? Co’z the syslog isn’t saying any problems going on :cold_sweat:

1 Like
#9

service uhttpd stop
then run the command from ps wwww | grep uhttpd on the console. It won't fork to background so any errors will be visible.

#10

Hello @trendy,

Here’s the output as per the commands you sent:

root@OpenWrt-1900:~# 
root@OpenWrt-1900:~# service uhttpd stop
root@OpenWrt-1900:~# ps wwww | grep uhttpd
 6574 root      1072 R    grep uhttpd
root@OpenWrt-1900:~# service uhttpd start
root@OpenWrt-1900:~# ps wwww | grep uhttpd
 6610 root      3956 S    /usr/sbin/uhttpd -f -h /www -r OpenWrt-1900 -x /cgi-bin -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 0.0.0.0:80 -p [::]:80 -C /etc/ssl/mycert2.crt -K /etc/ssl/mycert2.key -s [::]:443 -s 192.168.1.2:443 -q
 6658 root      1072 R    grep uhttpd
root@OpenWrt-1900:~#

It now works!!! See below:

image
image716Ă—146 6.35 KB

You now see padlock. It’s listening to port 443 now :smile:

I am just at a loss what solved it. One just stopped/start the service and the other was a process listing. I have restarted this a bunch of times before reaching out to you guys. :cry: so I’m clueless as to what solved it. Hope you can provide some clarification regarding my confusion. Thanks!

Sincerely,

Vince

#11

Hi @trendy,

I think I know now what the problem is:

There might be an issue the the uhttpd service startup during reboots. Co’z I tried to reboot router and https isn’t working again :cry:

But when I execute “service uhttpd stop” and “service uhttpd start” https is working again.

This also explains why my reboots wasn’t resolving eventhough I have correctly defined the ip addresses for port 443 https will listen to.

Having said that, the question now is, do you know where I can check startup parameters for the service?

Sincerely,

Vince

#12

Is the device taking settings from dhcp or has static IP?

#13

Hi @trendy,

It’s statically assigned see below:

image
image862Ă—763 64.9 KB

Sincerely,

Vince

#14

For some reason uHTTPd is not listening on the unspecified address 0.0.0.0.
Try to reset its config to the defaults, reboot the device and make sure the socket is not busy.

#15

I suppose the OP wanted it that way for some reason. But maybe it is better to just leave it to default 0.0.0.0:443 and see how it goes.

2 Likes
#16

Interface/socket binding is known to be problematic due to possible race conditions with network management services.
If possible, it's best to avoid it and utilize firewall to manage access permissions.

2 Likes
#17

Hello @vgaetera, @trendy,

Thanks for taking time to looking into my issue. Really am appreciating it. :smile:

So to summarize, I will just remove the 192.168.1.2:443 defninition for HTTPS in UHHTPD? I will just remove the higlighted entrie as seen below?

image
image1169Ă—641 84.6 KB

I can do that I’m just a home user so no need to have paranoid levels of security for me :stuck_out_tongue:

However, just curious though why is it when I restart the service it works just fine?

Sincerely,

Vince

#18

No, replace it with the following:

0.0.0.0:443
1 Like
#19

Hello @vgaetera,

I tried to apply the changes but it is not getting reflected when applied through LuCi. :frowning: it times out and rolls back the changes.

Will do it through the configuration file now. Will update you guys in a while of the results.

Thanks!

Vince

#20

Hi @vgaetera,

I can now confirm that HTTPS is now working again in LuCi even after reboot :slight_smile: Yipee! :slight_smile:

Thanks to you and @trendy for your support. :slight_smile:

Sincerely,

Vince

2 Likes