This is definitely normal behavior. The only way to get around this would be to configure the client to not verify the server certificate which is a security risk and is not best practice.
The idea is that if someone threw up a rogue AP with the same SSID and your users associated to it, they would receive a different certificate prompt which should throw a red flag (unforuntely it doesn't to college kids, they just click yes). tim ** Tim Cappalli*, *Network Engineer LTS | Brandeis University x67149 | (617) 701-7149 [email protected] On Mon, Apr 15, 2013 at 11:34 AM, Williams, Mr. Michael < [email protected]> wrote: > Our wireless network consists of a two Cisco wireless controller, 240 APs > and we use Cisco ACS 5.2 as our RADIUS server. One of our wireless > networks is configured to use WPA/WPA2 with 802.1x and PEAP w/ MSCHAP v2. > After updating the server certificate on the ACS, our wireless users were > asked to verify or validate the server certificate before gaining access to > the wireless network. This requirement generates numerous helpdesk tickets > and many more questions as to why the users must do this, when they don’t > have to do it on any other wireless network. I have asked Cisco for > assistance but they informed me that what we are seeing is the normal > behavior for the wireless supplicants and that the user must manually > verify the authentication server certificate when a wireless profile is > created for the first time or after the server certificate is changed on > the ACS.**** > > ** ** > > I know we are not the only one seeing this requirements, numerous other > University have publish wireless tutorials asking their user to verify the > certificate as part of the initial setup of the wireless profile. I know > we can eliminate this requirement in Windows machines by just unchecking > the validate certificate option, but this is not an option on iOS > machines. We use the 3rd party certificate by Incommon and have install > both intermediate and root certificate on the ACS.**** > > ** ** > > Has anyone found a solution to this problem? Or is this just the default > behavior of the supplicant that we are seeing?**** > > ** ** > > Thank you for your assistance.**** > > ** ** > > mike**** > > ** ** > > *Michael M. Williams* > > Network Systems Analyst**** > > Information Technology Services**** > > Tarleton State University**** > > 201st St. Felix Str.**** > > Box T-0220**** > > Stephenville, TX 76402**** > > ** ** > > *Information Technology Services staff will never ask for your password > in an email. Don't ever email your password to anyone or share > confidential information in emails.* > > * * > > *Confidentiality Notice: This electronic message, including any > attachments, is for the sole use of the intended recipients(s) and may > contain confidential and privileged information. Any unauthorized review, > use, disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all copies > of the original message.* > > ** ** > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
