Security

Was trying to get our wifi up and running with trusted certificates so nobody would ever have to click through any warning anymore and get used to this and actualy take notice somewhere down the line when they do get a valid warning.

 

For this we're using a publicly signed radius/webserver certificate on our Clearpass server. This works great without any warnings for guests on our guest portal and internal clients except for iOS clients.

 

The iOS clients keep throwing up a "not verified" for the certificate even though the certificate is issued by a root CA that is included in Apples own iOS 8: List of available trusted root certificates.

 

Does anybody have an idea why iOS would keep throwing up this warning with a completed trust chain? Or better yet, how to solve it?

There might be an intermediate cert not in the trust list. You should make sure all certs are combined into the cert on CPPM. It might also be trying OCSP lookup and that is causing the error. I couldn't tell you for sure without looking at it. You can test by emailing all the individual certs to a IOS device and installing one at a time to see what cert is causing the error.

I'm confused.. 

Why would the device need an explicit trust of the intermediate CA? If the root CA is trusted then automatically we can trust intermediate and finaly server certs no?

 

And OCSP.. wouldn't the supplicant be smart enough to know it's not possible the do an OCSP check before you're authenticated?

 

---

@KoenV wrote:

I'm confused.. 

Why would the device need an explicit trust of the intermediate CA? If the root CA is trusted then automatically we can trust intermediate and finaly server certs no?

 

And OCSP.. wouldn't the supplicant be smart enough to know it's not possible the do an OCSP check before you're authenticated?

 

---

Koenv,

 

Apple is probably the best person to asky why its supplicant behaves that way :  https://discussions.apple.com/thread/5967450

 

In addition, OCSP is only used to determine if a certificate is revoked or not.  That requires an internet connection, so it is not applicable in the 802.1x context from the client perspective, where authentication occurs before a connection is made. 

That specific not verified message is there because you have not previously defined the RADIUS server's identity. 

This will happen the first time the user hits a new authentication server for each SSID. 

The only way to prevent this is to pre-configure clients using Apple profiles (QuickConnect standalone, Onboard or Profile Manager)


Thanks, 
Tim

---

@cappalli wrote:
That specific not verified message is there because you have not previously defined the RADIUS server's identity. 

---

Do I understand that the issue is not the certificate itself but rather that I haven't told iOS anywhere what my radius server would be?

That kinda makes sense.

 

Gues this will be 1 warning our users will just have to click through untill we setup onboarding for them.

Thanks all for the responses!

Thats what I get for answering questions at 4 AM. :) Tim is correct. You will always see that on the first time you connect. I thought you were talking about the error showing up while you were running the onboarding process and the popup was showing during the profile install.

Hello

 

I am going a long way around the same issue with Support.

 

Is it fair to say that Apple IOS, reuqires the validation of the clearpass certificate through manual user validation when connecting via 801.1X on the initial connection. We only have an issue when connecting to the SSID for the 1st time and was expecting the local device Apple trust store to validate our Publicly signed certificate. We have no issues with Onboarding.

 

We have tested in IOS8 and IOS9 just this morning and behaviour is still the same.

 

Thanks

Ken 

So these devices are fully Onboarded or are they connecting using username/password?

Hello Tim,

 

No, we are not onboard yet and its the initial client connection via 802.1X to the Wireless/Clearpass infrastructure.

 

We have a private root CA for onboard so we expected to get the prompts for these certs. We are only asking about the intial cert "not verified" warning. See attached message that we receive when we connect to the SSID for the 1st time using our AD credentials.

 

Thanks

Ken

 

You will always see Not Verified or Not Trusted during initial connection
unless you Onboard or pre-configure using something like QuickConnect.



It's a normal part of the protocol.

So thats where I am confused.

 

We are using Onboard but 1st, we have to connect to the SSID (get the Not verified) before we can proceed to start the onboard process.

 

thanks

Ken

Yes, that's correct because you're using EAP-PEAP for the initial
authentication.

Hi Tim,

 

So, in the interest of user experience whilst trying to limit the number of SSID's - What is the best  or suggested practice to have employees access the onboarding feature?

 

We operate Windows, Most Linux verison , IOS , Android and we fully understand what Onboard supports. I personally don't like the idea of the all fiddly parts, look and feel to EAP-PEAP , just for getting to the onboard part.

 

thanks

ken

There is more a personal preference rather than a best practice realy.

If you do not like the dot1x fiddly parts, just start your onboarding from an open SSID. Problem solved.

Just have your users Onboard through your guest SSID. Put a link at the
bottom of the captive portal "Employees Enroll Here".

     Forgive me if I am being dense, but would you also expect this behavior if you are using Clearpass Guest with a single Guest user (i.e. CP Guest captive portal is configured with an "I Accept" button which uses a local account of the Clearpass server for all guests).

    I think I am running into this same issue but want to be sure.  Basically what is happening is that IOS devices can get ot the CP Guest Captive portal with no warnings, but when they click to accept and are redirected to the final landing page, they get the "not verified" warning and it lists the Aruba Controller's captive portal certificate.  The behavior is the same whether I use the default "securelogin.arubanetworks.com" cert or a cert generated for the controller from an enterprise wildcard.

 

Does your guest login page setup match the CN of the cert?

I'm not sure how to answer that and again forgive me if I am missing something really obvious. 

 

The Guest Login page in Clearpass Guest matches the CN of the of the SSL and RADIUS certificate installed in CP and the controller "Login Page" parameter (under L3 Authentication) is set correctly to direct clients to the Web Login configured on Clearpass.  Any type of Client device can get to the Captive Portal page with no problems or warnings.

 

The warning comes after a guest has "authenticated" by clicking the "I Accept" button and before they get to the final landing page (i.e. the redirect URL configured in the Captive Portal authentication profile on the controller).

 

Make sure this:

 

 

 

matches the CN of the captive portal certificate on the controller.

 

Sorry for reviving an old thread but in the IP address field in the screenshot what hostname should be used for a multiple controller environment? If I used a SAN certificate with each controller's FQDN which one do I populate that field with?

A single, generic name should be used for captive portal certificates. (ex: networklogin.domain.xyz)

Thank you Tim, and forgive me if im not understanding but should that generic name resolve to any IP address in the Guest DNS server? or is just a trusted cert passed to the client by the controller as part of the captive portal redirect? Similiar to the defualt securelogin.arubanetworks.com certificate?

 

Thanks,

No DNS needed. The controller presents it.

Hello,

We have godaddy cert installed on ClearPass under “radius/eap” and we get the “not trusted “ on Apple AND android as well as windows pcs. What could we be missing??

System CA trust has no bearing on EAP server certificate to SSID bindings. This message is completely normal.

You need to manually configure supplicants, manage the supplicant via GPO/EMM or Onboard the devices.

Thank you very much for confirming. I worked with TAC a couple hours on this and started wondering if it was normal. One click seems minimal effort but my client was pressing me to get rid of this.

With that said, what reason is there to actually add a public eap on ClearPass? None unless you follow through with the steps you mentioned? Sounds like we could have just stayed with the self signed cert.

Thanks!!!!!

If you don’t use a public CA-signed certificate, there will be another step which involves manually install the root CA.

In general, it is poor practice to use a legacy EAP method like PEAP.

Hi again, I left out one important detail. We have a GoDaddy certificate on ClearPass for Radius/EAP and when I connect for the first time on my iphone it shows that it is "not trusted" even though GoDaddy is in the apple and Android Root CA trust list. Does this mean that the cert is not trusted because of a possible name mismatch? I noticed on the controller under SSID security that the authentication server listed has a different name than what the cert does. I simply named it "CP" for ClearPass and the cert is more of a domain format.

No, it has nothing to do with whether the root is trusted. It’s a normal part of the PEAP and EAP-TTLS protocols.

Tunneled EAP methods should not be used with unconfigured supplicants.

You will always get Not Verified unless you pre-configure clients with a profile. It's a normal part of the EAP server validation process. It's just like the pop up you get on Windows and Mac. 


Thanks, 
Tim

I ended up going to the A/D and under each user's "dial-in" thumbtab changed the "Network Access Permission" to "Allow".  This has worked for all of my employees now.