behaviour change from 2.0 to 2.3 regarding NSP Profiles in iOS BYOD?

[Gustavo Novais]

Hello,

Just upgraded an ISE installation from 2.0.1 to 2.3p2. We were using single SSID BYOD with Apple iOS and Android before and everything was working perfectly. ISE is an intermediate CA to the private Root CA. The BYOD portal was assigned a public certificate from an external CA.

After the upgrade to 2.3 some stuff changed regarding the BYOD provisioning flows.

- in ISE 2.0 the apple iOS would get from the BYOD page two profiles. One containing the Root CA of the PKI infrastructure and the other with the wifi config as well as the device identity certificate and the  private PKI signing certificates (both ISE and ROOT CA certificate).

- in ISE 2.3, without config change, apple iOS is getting two profiles, but the first one that is sent is the root certificate of the public certificate in the BYOD portal and the second one is as well the wireless config and device identity certificate (as signed by the internal CA), but the signing certificates are now the public certificate instead of the private ones.

The immediate consequence is that EAP-TLS authentication fails, as the iOS device does not trust the server certificate presented by ISE, (we get OpenSSL remote alarm) even though the root CA certificate is included into the mobile profile.

Just to summarize - in ISE 2.0 iOS got

- Configuration profiles

     - private root CA

     - Mobile Config

          - wifi network config

          - device identity cert - signed by ISE endpoint subCA

          - certificate - private root CA

          - signing certificates - ISE cert and private root CA

in ISE 2.3 iOS gets

- configuration profiles

   - public root CA

   - Mobile Config

       - wifi network config

       - device identity cert - signed by ISE endpoint subCA

       - certificate - private root CA

       - signing certificates -public certificate + public Root CA

I've struggling to see where to modify this, but I'm hitting a dead end. If I set the BYOD portal with the internal certificate, then all BYOD redirection starts getting the "certificate not trusted error".

Is there anyway to change this behaviour in order to make the newly onboarded iOS establish EAP-TLS auth?

Thanks

Gustavo

[Craig Hyps · Accepted solution]

May be due to fix for CSCut36534  [ISE 1.3 in BYOD provisions Admin cert instead of BYOD portal Cert] delivered in ISE 2.2.

Previously the initial cert for web page was that of Admin portal (likely your private cert) and now uses public cert from BYOD portal.

[Gustavo Novais]

Hi Craig,

Thank you for your answer.

What I'm finding strange about this behaviour is that

the nsp profile includes the private root CA. Why are we then getting the remote ssl alarm that indicates that the cert is not trusted by the remote device? Does ios just ignore the profile information and looks at its global trust store, where effectively the private root CA does not exist.? It may be a question for apple, but even forcing the trust of the provisioned certificates does not make it better.

Is there any possibility of choosing which cert signs the nsp profile, or are we stuck with the one used by the byod portal (which will always be a public one...) ?

Thanks

Gustavo

[Craig Hyps]

You can only control by directing to portal used for NSP.

These links may help explain situation with iOS trust for EAP cert on first connect:

Re: EAP certificate - not trusted by "some" BYOD devices?

EAP and iPhone - Cisco Support Community

Note that there is reference to

CSCua97013

ISE-Apple IOS devices are asked to accept the "Not Verified" Certificate

  and this is primarily for tracking as issue held with Apple.

[Gustavo Novais]

Just to give a small return on experience.

- after switching the BYOD portal to use the internal certificate and back to public, besides trusting the presented certificates in iPAD, the provisioning started working.

TAC had suggested that for BYOD workflows they see that people just use their public ISE certificate even for RADIUS EAP authentications. This may make sense for some scenarios, nevertheless you always need to approve the certificate in General settings - about - trust..

Gustavo

[Jason Kunst]

Gustavo in the secure access wizard sandbox in dCloud using ISE 2.3 we have a public certificate setup

When going thru iOS BYOD flow it works fine. You don’t have to manually trust the ISE certificate as you mentioned

You may want to check that out and see what the difference is

Make sure you are running at least 2.3 patch 1 and have your iOS updated

[Jason Kunst]

Sorry this is for the dual SSID flow Where the user connects to an open network first. For the single SS ID or the flow where are you connect to a secure SSID first then you still need to trust the Certificate. This is an Apple requirement

[Gustavo Novais]

Hi Jason,

In deed, we are talking about single SSID. Good to know that for dual flow it is not needed.

The question I have in my mind is regarding the public vs private certificate setup. As we are also authenticating internal machines on the same ISE (GPO enrolled) I'm a bit reluctant about telling them to trust a publicly issued server certificate, given that their own certificates are issued from a private CA.

But this is more psychological than technical...

Gustavo

[Jason Kunst]

With iOS doing single ssid with a public certificate the behavior should be that the user has to trust the certificate pop up for initial dot1x exchange and that’s it. Onboarding takes place and the manual process you explained is not seen.

This is what I have observed in our dCloud environment for secure access wizard