I’ve been facing the same problem for months…
1- The user connects to the hotspot
2- proceed with authentication and click connect
3- CNMaestro redirects it to an internal URL of the controller on port 880 which is HTTP, but the destination is HTTPS:
At this point, we already have grant access coming from the radius server to authorize the user’s connection, the controller then receives this authorization and sends it to the user who then waits for the redirect to the status page, something like https://captiveportal.com /status. the problem is that the controller uses port 880 which is HTTP to redirect to an HTTPS website and this generates the certificate error.
The CAMBIUM team refuses to accept the fact that this final negotiation is the sole responsibility of the controlling company. It doesn’t make any sense for the radius server to tell the controller which URL it should mount or which port to use to redirect to the STATUS page.
Anyway, even if I leave the login success field blank, or enter any other website, the error persists.
I agree that it seems strange to use plain HTTP for this. But if we ignore that for a second, if you press Enviar memo assim, does the authentication complete successfully?
Hi Simon, Thanks for your reply…
yes man, it does…but this solution is not friendly for a non proficent user…
im with Zoox Smart Data and, for a couple of months had been with some guys from Cambium trying to solve this but, any of them could help me.
including saying that the problem would be in our backend that calls this final redirect in HTTP…
This doesn’t make any sense because our backend just responds to a request and sends the response via this same path with the radius username and password so that the controller authorizes the user and then redirects him to a status page or to a website that he was trying to get there.
On cell phones the problem is worse because the CNA goes up normally, but at the end of the authentication process, the screen turns completely white, preventing the user from interacting and moving forward.
Understood - I just wanted to make sure that the problem was only HTTP vs HTTPS.
I’ve found your ticket with previous discussion about this, which I will have a read through to try and understand in more detail. If this was a fundamental problem with the system, I would have thought we would have had more complaints, so it feels like something that we can resolve with appropriate configuration.
@Kunal_Solanki is the expert and will hopefully chime in with more guidance, but in the meantime, have you looked at these two documents in the Wi-Fi 6 documentation portal (I’m not sure which one applies to your situation):
This document has clear instructions and sample requests to be used along with kind of configuration required to be done under WLAN Guest Access. Based on the information provided by you it looks like you have enabled “External Portal Post Through cnMaestro” under WLAN Guest Access configuration as I can see the cnMaestro guest portal hostname being used here instead of AP IP address in the POST request sent to port 880 and this is leading to your certificate issue as of now. Port 880 is used for HTTP Post and Port 444 is used for HTTPS Post. Your external splash page is hosted on HTTPS and when you do HTTP Post some devices will flag it and show it as a warning of unsecured communication. To resolve all such certificate issues we had added support of this using cnMaestro API and the document “Integrating External Captive Portal with cnMaestro API.pdf” talks about how to integrate that. Let me connect with you directly to help you out in finding a usable solution.
Hi Alex, please note Kunal’s comment earlier " Your external splash page is hosted on HTTPS and when you do HTTP Post some devices will flag it and show it as a warning of unsecured communication." instead of HTTP POST, you can use HTTP GET to avoid cert error.
I think there is a misunderstanding here though. In the screenshot, Alex is trying to POST to /cgi-bin/hotspot_login.cgi on a cnMaestro Cloud hostname. This can never work, as hotspot_login.cgi runs on a WiFi AP, not on cnMaestro.
To work with cnMaestro Cloud, doesn’t the captive portal need to use the cnMaestro API to authenticate the session?
good morning/afternoon everyone,
So, the problem is partially resolved. On cell phones the connection normally occurs without SSL alerts, however on computers the alert is still shown.
I’ve already searched the entire internet for any tips to solve the SSL problem on computers, but without success.
I’m starting to think that this could be a bug, since the endpoint is the same, as well as the captive portal, for both connections, but somehow, CNMaestro understands when it is a CNA that is activating the portal and when it is a browser, and then it shows or not the certificate. very strange because I have never seen this type of differentiation.
Does this happen with the external Advanced Captive Portals (like the ones from GoZone WiFi or others)? We are looking to get either the free plan or one of the paid plans, but someone just told me to check here before signing up and I saw this post. According to their website, it should work fine with my existing Cambium APs
Do you know ZOOX SMART DATA?
This is the technology that, in addition to allowing access to the Wi-Fi network, collects, organizes, qualifies and extracts data from your customers in a consensual way and generates unique insights for your business. Real Time Interaction
With each access, new information and more added value to the business. Profile search, deterministic audience data, real-time geolocation targeting and different touchpoints. Mobile Experience
Consolidated dashboard, white label; splash customization; image and video dissemination; Amazon hosting; integration with APIs; Flow analysis; Big Data with customer data and more. Wi-Fi Monetization
Monetize your platform with space to run campaigns. Possibilities for those who are already Zoox customers, and for those who want to advertise for our inventory and connect with new an current customers.
