Wireless Access

hello Airheads folks

we too are having issue with FEDRAMP -config'd Guest users, unable to login to our Guest Wifi, quite likely due to the presence of this 'continue to portal page' link, which itself has an 'invalid certificate associated

on our 7200 platforms , using an Internet CA for Guest Portal name (assume it's issued to  wifi-a.contoso.com ) ...although our WAN DNS doesn't have any external records for ' wifi-a.contoso.com ' ....do i need to put one out there for that Cert validation to 'resolve as true' ?

and...any other pointers on WHERE to deal with any other re-direct or *.gstatic.com testing process ...... i presume it'd be in the VAP ....as it's not in any other areas of the Guest Wifi settings that i can see

( oh, yeah, and what's up with the checkbox for 'use purple wifi ' .... ? would use of that 'help' in getting over the hump of this wretched bad-ssl-validation our clients (mostly ANDROID related) seem to get ?

7210 / 7205 on AOS 8.10.x (latest) ....but been having this issue for several revs of 8.10.x 

thnx !

That is a lot of information and a lot of questions. It may make sense to work with your HPE Aruba Networking partner to get this sorted out.

I don't think FEDRAMP is relevant to the topic.
With AOS8 controllers, the controller will perform the redirect and need a valid trusted captive-portal certificate. In the guest logon role, you would redirect all HTTP (TCP port 80) traffic so that includes gstatic.com, and the controller when in the guest role will intercept and respond to DNS requests for the FQDN in the captive portal certificate (wifi-a.contoso.com in your case), so there is no DNS entry needed.
The redirect happens in the role.
Purple WiFi is a vendor that offers an external captive portal solution. If you don't use that solution, don't use the configuration option.

If you like to better understand the steps happening in Guest access with AOS, check this video or this older one.

Common issue if you have a valid public certificate installed, but the client still shows an untrusted site message, is that you missed the intermediate certificates in the import in your controller. Certificates uploaded to controllers (or APs) need to be 'chained', which means it has the server certificate but also all intermediate certificates up to the root.

Hope this helps to solve your problem.

hello Airheads folks

we too are having issue with FEDRAMP -config'd Guest users, unable to login to our Guest Wifi, quite likely due to the presence of this 'continue to portal page' link, which itself has an 'invalid certificate associated

on our 7200 platforms , using an Internet CA for Guest Portal name (assume it's issued to  wifi-a.contoso.com ) ...although our WAN DNS doesn't have any external records for ' wifi-a.contoso.com ' ....do i need to put one out there for that Cert validation to 'resolve as true' ?

and...any other pointers on WHERE to deal with any other re-direct or *.gstatic.com testing process ...... i presume it'd be in the VAP ....as it's not in any other areas of the Guest Wifi settings that i can see

( oh, yeah, and what's up with the checkbox for 'use purple wifi ' .... ? would use of that 'help' in getting over the hump of this wretched bad-ssl-validation our clients (mostly ANDROID related) seem to get ?

7210 / 7205 on AOS 8.10.x (latest) ....but been having this issue for several revs of 8.10.x 

thnx !

thnx very much for the info Herman! i believe you probably hit the mark in the last part.... of not-chaining-the-certs i get back from Internet CA .

do you know if this is a task that Aruba/HPE TAC assists with ?  likely in past 6+ years we've NEVER done the chaining of Cert and Intermediate Cert....  :-( 

That is a lot of information and a lot of questions. It may make sense to work with your HPE Aruba Networking partner to get this sorted out.

I don't think FEDRAMP is relevant to the topic.
With AOS8 controllers, the controller will perform the redirect and need a valid trusted captive-portal certificate. In the guest logon role, you would redirect all HTTP (TCP port 80) traffic so that includes gstatic.com, and the controller when in the guest role will intercept and respond to DNS requests for the FQDN in the captive portal certificate (wifi-a.contoso.com in your case), so there is no DNS entry needed.
The redirect happens in the role.
Purple WiFi is a vendor that offers an external captive portal solution. If you don't use that solution, don't use the configuration option.

If you like to better understand the steps happening in Guest access with AOS, check this video or this older one.

Common issue if you have a valid public certificate installed, but the client still shows an untrusted site message, is that you missed the intermediate certificates in the import in your controller. Certificates uploaded to controllers (or APs) need to be 'chained', which means it has the server certificate but also all intermediate certificates up to the root.

Hope this helps to solve your problem.

hello Airheads folks

we too are having issue with FEDRAMP -config'd Guest users, unable to login to our Guest Wifi, quite likely due to the presence of this 'continue to portal page' link, which itself has an 'invalid certificate associated

on our 7200 platforms , using an Internet CA for Guest Portal name (assume it's issued to  wifi-a.contoso.com ) ...although our WAN DNS doesn't have any external records for ' wifi-a.contoso.com ' ....do i need to put one out there for that Cert validation to 'resolve as true' ?

and...any other pointers on WHERE to deal with any other re-direct or *.gstatic.com testing process ...... i presume it'd be in the VAP ....as it's not in any other areas of the Guest Wifi settings that i can see

( oh, yeah, and what's up with the checkbox for 'use purple wifi ' .... ? would use of that 'help' in getting over the hump of this wretched bad-ssl-validation our clients (mostly ANDROID related) seem to get ?

7210 / 7205 on AOS 8.10.x (latest) ....but been having this issue for several revs of 8.10.x 

thnx !