Using linksys-wrt1900acs, I logged into LuCI and generated a backup. then (using LuCI) I flashed the 18.06.2 firmware with the option unticked to remember settings.
After the flash, I went into the newly flashed LuCI and
opkg update
opkg install luci-ssl
Then I restored the backup I made. Afterward, I cannot access LuCI. I basically get an ERR_CONNECTION_REFUSED every time I try.
I can successfully login to the router via SSH and all networking functions seem to be working. But I cannot get to LuCI via a web-browser.
Using the alternate partition, I switched back to version 18.06.1. Then I generated a new backup. Then I reflashed 18.06.2 and restored to the backup. Same problem. Everything works except LuCI.
I'll try skipping the restoring to backup part next and rebuild from the factory settings. But curious if anyone has experienced this before and has an idea of what's happening.
There is something wrong in ssl certificate or uhttpd settings.
One possibility might be an old certificate (in your backup) , which has been created with some encryption that has been disabled in the current mbedtls library.
You might flash it , install luci-ssl , but not restore backup. Then test if you can connect to LuCI.
Other option is to delete uhttpd's certificates from /etc and restart uhttpd, so that it recreates the certificate.
Third thing is to use a different browser to test if it is just too protective.
Fourth option is to copy fresh uhttpd config file from /rom/etc/config
Also check if the time and date are correct. If it is not the correct one or if the certificates are outdated it will also give an error.
Regardless post here the uhttpd configuration and verify that the certificates exist in the defined location.
So far you are only one who has this HTTPS problem, I think. So it is likely something in your settings.
My own 18.06 build has worked ok with Openssl based HTTPS, but I installed now mbedtls and libustream-mbedtls to mimic your luci-ssl config. Worked ok, and worked also ok after letting it to re-create the key & certificate.
Ps. It is a week since the 18.06.2 release, so if there would be a general HTTPS problem, the forum would be full of bug reports by now. You are not the only one that uses HTTPS with LuCI...
# Server configuration
config uhttpd main
# HTTP listen addresses, multiple allowed
list listen_http 0.0.0.0:80
list listen_http [::]:80
# HTTPS listen addresses, multiple allowed
list listen_https 0.0.0.0:443
list listen_https [::]:443
# Redirect HTTP requests to HTTPS if possible
option redirect_https 1
# Server document root
option home /www
# Reject requests from RFC1918 IP addresses
# directed to the servers public IP(s).
# This is a DNS rebinding countermeasure.
option rfc1918_filter 1
# Maximum number of concurrent requests.
# If this number is exceeded, further requests are
# queued until the number of running requests drops
# below the limit again.
option max_requests 1
# Maximum number of concurrent connections.
# If this number is exceeded, further TCP connection
# attempts are queued until the number of active
# connections drops below the limit again.
option max_connections 100
# Certificate and private key for HTTPS.
# If no listen_https addresses are given,
# the key options are ignored.
option cert /etc/uhttpd.crt
option key /etc/uhttpd.key
# CGI url prefix, will be searched in docroot.
# Default is /cgi-bin
option cgi_prefix /cgi-bin
# List of extension->interpreter mappings.
# Files with an associated interpreter can
# be called outside of the CGI prefix and do
# not need to be executable.
# list interpreter ".php=/usr/bin/php-cgi"
# list interpreter ".cgi=/usr/bin/perl"
# List of prefix->Lua handler mappings.
# Any request to an URL beneath the prefix
# will be dispatched to the associated Lua
# handler script. Lua support is disabled when
# no handler mappings are specified. Lua prefix
# matches have precedence over the CGI prefix.
list lua_prefix "/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua"
# Specify the ubus-rpc prefix and socket path.
# option ubus_prefix /ubus
# option ubus_socket /var/run/ubus.sock
# CGI/Lua timeout, if the called script does not
# write data within the given amount of seconds,
# the server will terminate the request with
# 504 Gateway Timeout response.
option script_timeout 60
# Network timeout, if the current connection is
# blocked for the specified amount of seconds,
# the server will terminate the associated
# request process.
option network_timeout 30
# HTTP Keep-Alive, specifies the timeout for persistent
# HTTP/1.1 connections. Setting this to 0 will disable
# persistent HTTP connections.
option http_keepalive 20
# TCP Keep-Alive, send periodic keep-alive probes
# over established connections to detect dead peers.
# The value is given in seconds to specify the
# interval between subsequent probes.
# Setting this to 0 will disable TCP keep-alive.
option tcp_keepalive 1
# Basic auth realm, defaults to local hostname
# option realm OpenWrt
# Configuration file in busybox httpd format
# option config /etc/httpd.conf
# Do not follow symlinks that point outside of the
# home directory.
# option no_symlinks 0
# Do not produce directory listings but send 403
# instead if a client requests an url pointing to
# a directory without any index file.
# option no_dirlists 0
# Do not authenticate any ubus-rpc requests against
# the ubus session/access procedure.
# This is dangerous and should be always left off
# except for development and debug purposes!
# option no_ubusauth 0
# For this instance of uhttpd use the listed httpauth
# sections to require Basic auth to the specified
# resources.
# list httpauth prefix_user
# Defaults for automatic certificate and key generation
config cert defaults
# Validity time
option days 730
# RSA key size
option bits 2048
# Location
option country ZZ
option state Somewhere
option location Unknown
# Common name
option commonname 'OpenWrt'
# config httpauth prefix_user
# option prefix /protected/url/path
# option username user
# option password 'plaintext_or_md5_or_$p$user_for_system_user'
I changed it to '3' and then rebooted and now I can connection to https.
But as you can see from my original flash etc, I did nothing to alter the default config after flash. (other than install ssl luci). So why is option max_requests set to '1'?
Can you guys check your config and see what your option max_requests is set to?
Take a look at this. Can someone comment on the differences and let me know how this compares to what you're seeing on your box?
Here are some differences:
option max_requests '3' was original '1' (before I changed it to '3')
option lua_prefix '/luci' (which was in 18.06.1) is missing from 18.06.2
option lua_handler '/usr/lib/lua/luci/sgi/uhttpd.lua' (which was in 18.06.1) is missing from 18.06.2
I have max_requests 3 and I never tweaked that. But I am keeping settings between upgrades. I can see in uhttpd-opkg defaults the value is 1.
I just tried with max=1 and it worked on Firefox 60.5.0esr.
Yes, I had tried different browsers before I even posted here. All browsers have the same problem and won't connect when https is tried. No issues with 18.06.1, so it is weird.
If anyone learns more about this, please let me know. Is it possible something is wrong with the hardware of the router?
I have two identical wrt1900ACS. I flashed WRT1900ACS (1) to 18.06.2 and then restored my backup. Everything working fine.
I then flashed WRT1900ACS (2) and restored my backup. And HTTPS will not connect. Everything else appears to be working fine. Before I restore my backup (after installing LuCI SSL), I cannot get HTTPS connection until after I modify the max_requests to 2+. But after restoring my backup HTTPS will not work, even though my backup has a max_requests of '3'. So this very puzzling as to why the first router works fine and second one will not work with HTTPS. For now I am having to keep the 2nd router at 18.06.1.
I believe I may have found the problem as I have been able to reproduce the failure to access LuCI over HTTPS at will by changing the "list listen_https '0.0.0.0:443'" setting. Please see this thread I started to explore the issue: Is this a bug in 18.06.2: list listen_https '0.0.0.0:443
No this shoudl not be a problem. It actually means that the UI is listening on all interfaces. You probably want to put in the IP address of your LAN interface, so that nobody can login from the WAN interface.