Android 6.0 BYOD On-boarding fails with Certificate Generation Failed error using Network Setup Assistant 2.2.0.54

[rick505d3]

Hi, Using ISE 2.2, Android 5.0 devices are successfully going through the BYOD provisioning flow. Android 6.0 devices, however, fail every time on "Installing Certificates..." screen on the agent with the message "Certificate Generation Failed". Error screenshot attached. This happens with both the Single-SSID or Dual-SSID method of on-boarding. The Dual-SSID method uses an Open Auth Guest WLAN and redirect to BYOD portal for qualified users. ISE, acting as Sub-CA to the corporate Root CA, issues certificates to the BYOD devices. The "spw.log" file on the Android 6.0 (Samsung, LG) device logs this after it downloads the xml file from ISE node: ..... 2017.02.21 16:33:32 INFO:EST Server =ise02.example.com 2017.02.21 16:33:32 INFO:EST Server port =8084 2017.02.21 16:33:32 INFO:ISEDownloadProfileAsynchTask.onPostExecute :PASSED 2017.02.21 16:33:54 INFO:Making SCEP call 2017.02.21 16:33:54 INFO:Generating RSA key with key size: 2048 2017.02.21 16:33:56 INFO:Going to call EST server with args: cn = stuarts@example.com, un= stuarts@example.com, sn= ise02.example.com, sp =8084, cur= P-384, ca_certs length = 8486 2017.02.21 16:33:56 INFO:Calling native logger init with : /storage/emulated/0/Download/estlog.txt 2017.02.21 16:33:56 INFO:SPW profile is having certificate parameters 2017.02.21 16:34:44 INFO:EnrollCert Native returned pem len = 16384 2017.02.21 16:34:44 ERROR:ISEEnrollmentAsynchTask 2017.02.21 16:34:44 ERROR:java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.security.cert.X509Certificate.toString()' on a null object reference 2017.02.21 16:34:44 ERROR:Attempt to invoke virtual method 'java.lang.String java.security.cert.X509Certificate.toString()' on a null object reference 2017.02.21 16:34:44 INFO:Internal system error. The same execution point in the "spw.log" for the Android 5.0 (Samsung) device goes through successfully: ..... 2017.02.21 17:03:35 INFO:EST Server =ise02.example.com 2017.02.21 17:03:35 INFO:EST Server port =8084 2017.02.21 17:03:35 INFO:ISEDownloadProfileAsynchTask.onPostExecute :PASSED 2017.02.21 17:03:35 INFO:Making SCEP call 2017.02.21 17:03:35 INFO:Generating RSA key with key size: 2048 2017.02.21 17:03:36 INFO:SPW profile is having certificate parameters 2017.02.21 17:03:36 INFO:Cert request pending - Making pending cert call 2017.02.21 17:03:38 INFO:checkServerTrusted call 2017.02.21 17:03:38 INFO:Generated cert from SCEP server = [0] Version: 3 ..... The closest I could find is this bug "CSCug69605" although the log message is different to what I get and using different ISE version Has any one seen this before? Any workaround? Regards, Rick.

[John C · Accepted solution]

I have same exact issue on a Motorola device running android 7

TAC originally recommended I perform the steps in the following youtube video however it did not resolve my issue. It may fix your issue. 

https://www.youtube.com/watch?v=z0sRiffVdpg

If I get a solution I'll post it

[rick505d3]

Thanks for sharing the video and the workaround in the video. I will give it a go and and update here if it works in my case. 

[John C]

Closed out my TAC Case

I needed the fix from the video and an ALC I was using had a typo in it. 

[jacob.fredriksson]

If I may ask, is your ISE deployment upgraded from ISE 2.1 to 2.2 or is it an entirely new ISE 2.2 deployment?

[John C]

Mine was an upgrade 2.1 to 2.2

[jacob.fredriksson]

We got it working now, turns out we needed to open another port through the firewall from the BYOD-network (where the Android client is) to the ISE-servers. This was port TCP 8084, as shown in the opening posters log from the Android device. In ISE 2.1 we didn't need to have this port open to on-board Android devices.

.......

"2017.02.21 16:33:32 INFO:EST Server port =8084"

.......

We also applied the new AuthZ rules shown in the Cisco ISE video above.

What is not shown in the video is that the certificate request from Android to ISE using EST-CSR is sent using PAP-ASCII, which forced us to make a new top-level condition containing only one of the two "fixes" from the video (both of them work). Because our normal AuthZ top-level conditions are based on "MAB" and "Wireless_802.1X", the EST-CSR request fell through all of our rules and got denied at the end at first but after creating a new top-level condition, it is now working. While this is a deployment specific error based on how you match and group  your rules, it's good to know.

[ciscoworlds]

I'm using ISE 2.4 patch 1 and Android 7.0; But this workaround didn't work for me. I'm still getting the same error message stating that "certificate generation failed". 

[Eduardo Ferreira Fernandez]

Hi, i have the exact issue, what do you mean by ALC?

Thank you

[rick505d3]

Hi John,

After a bit of delay, we tested the workaround in the youtube video and either of the rules make the BYOD onboarding of Android 6.0 devices work. Thanks for sharing.

Regards, 

Rick. 

[Ivan Villagomez]

I would like to add that PAP-ASCII was added to my  "Allowed Protocols Services" and it worked. 

[spitalfmi]

Hi,

I got the exact same issue with ISE 2.4 and Android 8.0. The spw.log of NSA shows the following:

2018.05.25 11:05:59 ERROR:ISEEnrollmentAsynchTask
2018.05.25 11:05:59 ERROR:java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.security.cert.Certificate.toString()' on a null object reference
2018.05.25 11:05:59 ERROR:Attempt to invoke virtual method 'java.lang.String java.security.cert.Certificate.toString()' on a null object reference

I followed the instructions given in the video but still no success. My AuthC Rules looks like this:

PAP/ASCII is allowed.

Any help is appreciated,

Marc

[hslai]

Please use RADIUS live logs to check whether the auth attempt matched correctly. Keep in mind to enter the same password used in joining the WPA2-Enterprise WiFi network, in case single-SSID BYOD, when the Network Setup Assistant app prompts for the network password.

[spitalfmi]

That's everything I get from radius live logs when filtering by the mac address of the android device:

As you can see, it is not hitting the EST rule. My BYOD rule set looks like this:

When the NSA is asking for the network password, I provide the domain password.

[ciscoworlds]

I also have the exact same issue. I'm using ISE 2.4 patch 1, Android device 7.0 and Network Setup Assistant v2.2.0.54.

I've created a new condition as stated regarding EST but I got no hit on that authz rule. 

As seen I put this new authz rule before others, but it shows no hit at all. I found some said that use manual certificate input but it is a silly solution, as BYOD means "simplicity" for regular clients to connect them to the network. If I should deploy certificates manually to 1000 users, I would prefer to not allow anybody to connect their personal devices to the network at all!!

It should not be such a cumbersome; it has been 2 weeks that I'm playing with these stuffs just to allow BYOD connectivity. What a mess ISE!