https redirect results in inescapable certificate errors in Firefox

[technosopher]

The current image does not contain any logic for generating new, individualized https certificates; as a result, all devices running Commotion are essentially using the same certificate. This fact constitutes an issue in and of itself, but it has become show-stoppingly problematic with the introduction of the forced-redirect to https for all administrative panels. At least in Firefox, the browser will allow the https connection to the first device with the standard cert warning - but attempting to connect to any other devices will result in an inescapable error (ie, one that does not let the user through, no matter what they do) indicating that the browser has seen the current cert fingerprint before, associated with a different device, and is hence unwilling to let a new device use it.

[jheretic]

Actually, every node is creating its own certificate; it gets generated on first boot. The problem is that when you permanently save the cert, your browser maps it to an IP address. If you primarily access the node through the 192.168.1.20 alias, rather than its LAN address, when you save the cert it gets associated with the 192.168.1.20 address. When you go to another node, it gets the same IP address but a different certificate (actually if it were the same cert, you wouldn't get this error at all), thus causing the error. This only occurs for users who primarily connect via the 192.168.1.20 alias rather than getting a DHCP lease. The solution is to change the 'thisnode' alias to point to the main LAN IP, and remove the 192.168.1.20 alias. The first part of the solution at least is in DR2. I'll leave this issue open in the meantime until DR2.1 changes the IP addressing, which will address the second part.

[technosopher]

Whoops - thought I saw identical fingerprints for two different nodes, but I must've just been looking at a cached copy of the page or something. Thanks for the clarification!

[areynold]

Just to clarify, is the remaining piece of work to remove 192.168.1.20 as a local alias, forcing users to use thisnode or the node's unique IP address to connect?

[jheretic]

Just added an issue in commotion-openwrt to address this last piece of work. I think the bigger issue is to make sure our documentation is consistent with the change.

[areynold]

A fix to opentechinstitute/commotion-router#44 is ready to go. I will submit a pull request when Darby is ready to publish an update to https://commotionwireless.net/docs/cck/installing-configuring/install-ubiquiti-router

[critzo]

I'm assuming the cck page change is this portion, nearly at the bottom of the page:

Then, browse to the Commotion Web interface by entering http://192.168.1.20 in your Web browser again. If you see the Commotion screen, congratulations! You now have a Commotion wireless node!

If so, what should the instructions read?

Allow your computer to receive a DHCP lease from the router. Then, browse to the Commotion Web interface by entering http://thisnode into your Web browser. If you see the Commotion screen, congratulations! You now have a Commotion wireless node!

[areynold]

@critzo: Something along those lines, yes. Darby asked about those instructions this morning and may already have something in draft.

[jheretic]

This is issue was addressed by changing the configuration for the thisnode alias.

[areynold]

Reopening until the documentation catches up to the fix

[areynold]

Page text is easy to change, but 192.168.1.20 appears in a graphic in that document as well. Looking for source.

[areynold]

Handed off to content authors. Will be fixed in R1.