Setting up certificate based authentication can be extremely difficult and frustrating. It is great when it works, but getting to that point can be a slow and painful process if inexperienced with implementation and general knowledge of certificates. This document is meant to serve as a guide for troubleshooting the “simple” things that seem to prevent successful implementation of certificate authentication for wireless networks, and specifically as it relates to MobileIron configurations of mobile devices.
Background / Cause
Many organizations are moving toward ease of administration, better security, and better overall end-user experience. MobileIron provides all of these for mobile devices, but getting the right configurations can sometimes be more difficult than originally anticipated even with a solid product like MobileIron. Certificate authentication has many benefits, however, easy setup and implementation is not one of them. This has caused a need to review and document troubleshooting steps when things go wrong with certificate authentication.
Known Issues / Troubleshooting
Problem: | SSID is not showing up for a hidden network, and the device is not connecting to the wireless network.
Solution: | In this scenario, 2 things are present and should be noted.
- The SSID is hidden
- The device, even though a profile has been applied with all the configuration information fails to connect to the network.
First, if the SSID of a network is hidden, on the configuration page of a wireless network configuration for that SSID, the check box “Hidden Network” must be selected. Failure to select this option will prevent the device from even looking for the SSID.
Second, if manually typing the SSID into the “other” option for network selection on the device seems to work, but fails initially, or complains about a certificate, the trusted certificate section has been incorrectly configured in for the wireless configuration. The mobile device attempts to verify the identity of the device / server at the other end of the connection, but if the certificate of that device / server is not trusted, and / or the certificate common name is not listed in the “trusted certificates” list in the configuration, the connection will fail.
To resolve these issues, verify the “Hidden Network” check box is selected for wireless networks using the hidden SSID option. Attempting to connect to a hidden network without this selected will fail to automatically connect every time. This is important for hidden networks. Save the configuration and force the device to check in.
The certificate should be verified by the device for it to connect without issue. Once a certificate has been verified it will continue to connect. However, the initial connection will pop-up a warning asking for end-user interaction to approve the certificate the device is not able to verify. Most organization want to avoid this extra step for end-users even if it is only a one-time occurrence. In order for this to happen, the certificate must be from a valid 3rd party trust source (internal certificate authorities are acceptable as long as the mobile devices trust that source). Next, the common name of the device or server displayed on the certificate needs to be added to the “Trusted Certificate Names” list of the configuration. The “Allow Trust Exceptions” will not “fix” this problem (at least with iOS devices) so it is important that the common name on the certificate of the device or server is put in the “Trusted Certificates” list.
Problem: | An existing configuration for the Wireless network already exists on the device. If the device has already been configured to access the wireless network, the profile fails to be properly installed and if a selective wipe is sent to the device, the wireless configuration will remain on the device.
Solution: | Do not allow wireless access to mobile devices without acceptance of company policies and management of the devices in MobileIron. This is where using certificate authentication is beneficial.