Ntopng https redirect / protocol error after configuration in version 2.4.1

[ProgressCity]

Greetings all!

I'm running pfsense with webconfigurator using https on a nonstandard port (not 443), anti-lockout rule disabled, and webgui redirects disabled.  I'm NOT running anything behind HAPROXY currently.    I'm having an issue with getting ntopng to properly redirect after an installation. Once I set my general options (password, Interfaces, DNS mode, Local Nets etc etc), and update my GeoIP Data. I enable Ntoppng, and save.
Once the configuration is there, I click Diagnostics>ntopng and am immediately redirected to a browser error page:
Chrome: This site can’t provide a secure connection
<firewall>uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol The client and server don't support a common SSL protocol version or cipher suite.

Firefox:
Secure Connection Failed
An error occurred during a connection to https://<firewall>:3000. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.

IE:
This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://<firewall>:3000 again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.

I've tried:
uninstalling, deleting the configs and /var/db/ntopng directory and reinstalling and reconfiging.
made sure redis server was running and listening on 127.0.0.1:6379 with proper entries in /etc/rc.conf for reboots
Verified ntopng was running and at least listening on port 3000.
Verified the /usr/local/etc/redis.conf configs were correct

After some messing around I'm sure this has something to do with HTTPS / HSTS. I've tried configuring a DNS entry resolving to just a single hostname (and FQDN obviously) to bypass the limitation, though it's not working not with HTTP or HTTPS. I've tried using an additional CARP IP, I've tried tying it to the LAN Physical IP. For anyone familiar with configuring darkstat (http only with a webconfigurator on https) I tried to work around it in a similar way, however there is no such option for a web hostname as there is in darkstat.

Aside from known bugs with limiters and the like, I'm not having any other issues but this one seems a bit weird.
  CONFIG FILES 
Content of redis.conf

bind 127.0.0.1
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /var/run/redis/redis.pid
loglevel notice
logfile /var/log/redis/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/db/redis/
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

No errors in ntopng log
Any assistance would be helpful and greatly appreciated!</firewall></firewall></firewall>

[jgravert]

I realize this is an old post. I thought I would respond so others will find a solution.

The issue is usually two fold.

New browser versions do not like mismatched certificates and your firewall software may also be blocking the SSL certificate.

First here is a link to some general information on deactivating SSL scanning on some firewall softwares. (scroll down to the middle bottom of this page for that section) https://ugetfix.com/ask/how-to-fix-err_ssl_version_or_cipher_mismatch-error/

Second and a more permanent fix is to create a new CA and Certificate then adding the CA to windows or the browser. Doing this will allow you to keep your firewall SSL scanning active and still allow you access to pfsense. Just be certain to follow the instructions precisely. https://www.ceos3c.com/pfsense/pfsense-generate-ssl-certificate-https-pfsense/

NOTE: You may find that you need to flush your DNS cache on Chrome afterwards to get things going again. Also possibly a browser reset. I also found some Chrome extensions do not play well with certain sites. So also try Incognito Mode (which disables extensions for that session) to see if an extension might be causing trouble.

EDIT NOTE: Also if you happen to have the latest version of Bitdefender they changed the name of Scan SSL. I'm attaching screenshots of that setting. It is the same setting.

Hope this helps.