Security

last person joined: 18 hours ago 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

PEAP using Public Certificates - Clients still prompt to accept / trust even with valid root CA

This thread has been viewed 2 times
  • 1.  PEAP using Public Certificates - Clients still prompt to accept / trust even with valid root CA

    Posted Feb 22, 2012 06:17 PM

    Hi All,

     

    I am currently deploying an Amigopod server in a University environment and have run into an issue with PEAP certificate trust which i was hoping to seek some real world advice on.

     

    The issue is that we are using an Entrust SSL certificate on the Radius server of Amigopod to provide server authentication for PEAP / MSCHAP.

     

    The certificate seems to be correct and works fine however what we are finding is that when a user connects to the wireless for the first time from a Windows 7 device or iOS device, they are prompted with a security warning advising that the certificate is not trusted.

     

    I have checked that the root CA for the issuer (Entrust 2048) is installed on the PC's Trusted Root CA folder, I have also verified that the same CA is listed as supported in the iOS release.

     

    Some reading i have done on other forums and this one suggest that this is the default behaviour as the CA is not trusted at the WLAN  profile level until the first connection is successful.

     

    After the first connection, the user is never prompted and it seems to be fine.

     

    I have tried also installing the L1C intermediate CA certificate onto the Windows machine however this issue still occurs.

     

    The trust seems to be fine when accessing the https interface of Amigopod as the browser shows no errors.

     

    I am hoping to find some accurate explanation / workaround for this so i can inform my client as they are questionining the benefit of a Public CA when they can't utilise the trust defined in the end user devices.

     

    Thanks in advance.

     

    Scott



  • 2.  RE: PEAP using Public Certificates - Clients still prompt to accept / trust even with valid root CA

    EMPLOYEE
    Posted Feb 23, 2012 11:29 AM

    I think I know what is going on here.

     

    The problem is that the cert you are using for PEAP has either an OCSP or CRL listed in the cert. What that means is that in order for the client to see that cert as still being valid, it needs to verify it via the OCSP or CRL. But how can a client do that without an IP address?

     

    The answer is, it can't.

     

    The only workaround I know of is to create your own cert without an OCSP or CRL. But that cert would have to be installed (or the root that created it) via Group Policy or a captive portal on an open SSID (via a utility or manual install).



  • 3.  RE: PEAP using Public Certificates - Clients still prompt to accept / trust even with valid root CA

    Posted Feb 23, 2012 03:03 PM
    Thanks for the detailed reply, that certainly seems to make sense as dar as what we are seeing.

    Unfortunately gpo isn't an option as this is for university students and mobile devices.

    We may need to ditch the public very in this case although it does seem to be very limiting as far as 802.1x goes.