Apple clients & 802.1x / WPA2-Enterprise

[Y C]

Not sure if this is the right place to start on this. We have our WLC's integrated with ISE and AD. Our production ssid uses dot1x. We have roughly 15k windows domain devices and other various personal devices users bring in that seem to work fine. An issue started cropping up with Apple devices specifically. I want to say this started once IOS12 was released late last year but can't be 100% positive.

ISE passes the EAP cert through the controller to the client. Once you select the ssid and enter in the domain id and password the client prompts you to accept the certificate all as expected for the initial connection. 

Two issues -

1. The cert prompt shows it has expired. If you tap the details to view the cert you can clearly see that the current date is passed the "valid after" date and is years before the "expires on" date, so the cert should not be considered expired. Once you trust the cert you connect and pass traffic as normal. This behavior is repeatable and consistent - if you forget and re-connect to the network the same thing happens.

I found an old apple ipad running ios 9 and it does the same thing described in #1.  Android devices don't do this but they ignore the cert all together. Windows (both domain and non-domain) devices don't do this.

Once you trust the device and continue on, you will randomly get prompted to re-trust the cert. Sometimes it shows it's expired as described in #1, sometimes it doesn't... but you will eventually get prompted. It may be a day, or a week, but eventually the prompt to re-trust the previously trusted cert does come up.

I'm leaning towards it being an apple issue - it should never mark a valid cert expired and shouldn't prompt to re-trust something that already was. Just looking for any ideas or others experiences.

[Y C]

Note - the cert was issued by one of our domain controllers that also acts as a CA. Don't imagine this matters though. Also I passed the cert through a checker found online and it confirms the dates.

[Freerk Terpstra]

Apple clients (iPhone and iPad) will by default ask the end-user to verify the RADIUS server certificate. This happens during the initial connection and when the certificate has been changed. Using a trusted certificate doesn't change this. The only way to get rid of this, is by using a MDM or on-boarding solution so that the device is informed about which certificate it can expect. That way you will see the green "trusted" icon during the initial connection instead of the "unexpected" red one.

Do make sure that all of your RADIUS servers are using the same certificate to start with. When more BYOD devices are going to use your infrastructure it might be a good idea to not use your own PKI for the RADIUS server certificate. Some clients don't allow a RADIUS server certificate signed by an untrusted CA, same goes for using a wildcard certificate (wildcard as SAN is fine in my experience).

Last but not least, you might want to inform your end-users about expected client behavior upfront. They should check the serial number of the presented certificate to make sure nobody is performing a men in the middle attack, however that might be wishful thinking depending on your end-users.

Please rate useful posts... :-)

[Y C]

Yes, its expected to happen initially and upon cert change. It's not expected to happen randomly after accepting the cert and no changes have been made.

Also when it does prompt you, it shouldn't tell you it's expired when it really isn't.

All our ISE policy nodes do have the same EAP cert.

[patoberli]

Make 100% sure it's the same EAP cert, compare the thumbprint. If for whatever reason another cert is offered (or somebody is doing a man in the middle attack) you will get re-prompted for the validity.
I haven't seen this in my environment with BYOD clients. I'm sure many iPhone users are already on iOS 12 and would have raised this, if it was an issue here.

[Y C]

Same thumbprint and serial number.

Even if we ignore the repeated prompt issue, it's still bizarre that a device would mark it expired even though the current date falls within the "not before, not after.." range.

[Y C]

I think some screenshots will help. These screenshots were taken from an iphone at the same time last month.

[patoberli]

5 years validity?
That's very uncommon, because certificates, starting somewhen 2018 shouldn't anymore be valid more than 2 years.
See for example here: https://knowledge.digicert.com/generalinformation/INFO4906.html
Maybe that's why the certificate is marked as invalid.

Also check the following requirements (source https://discussions.soti.net/kb/ios-12-devices-fail-to-enroll-with-error-an-ssl-error-has-occurred-and-a-secure-connection-to-the-server-cannot-be-made):
The SSL server certificate must meet the following requirements:
· Be signed with one of the following types of keys:
o RSA key with a length of at least 2048 bits
o ECC key with a size of at least 256 bits
· The certificate’s hashing algorithm must be SHA-2 with a digest length, sometimes called a “fingerprint,” of at least 256 (that is, SHA-256 or greater)

----
I assume the intermediate / root certificate which are possibly implemented in the certificate are still both valid?

[Y C]

That blurb from apple appears to come from this whitepaper they've published: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

This is a SHA-1 signed cert which contradicts apple's requirements... however it specifies the signing requirements start with IOS-11 (this problem started with IOS12 for us it seems), and these are specific to browser TLS connections to a web server - I'm not sure if the same thing applies to PEAP/MS-CHAPv2 ? Even if it does, this is a trust once and done thing.

Root and intermediate certs are still valid as well, until 2023.

[ajc]

Whenever you are roaming from AP-1 to AP-2 and if you are using 802.1x, a brand new authentication happens and therefore depending on your certificate implementation for EAP-TLS or PEAP, the untrusted certificate warning would show up.

On Windows devices that does not happen because the profile you have configured probably is NOT validating the server certificate OR the intermediate and root CA that signed the cert is part of the TRUSTED CERTIFICATE AUTHORITIES DB on Windows. I mean:

[ajc]

Another question, are you using a PUBLIC CA to sign the cert or an Internal CA Server?

Let me give a try, I will push from my MDM a cert into my IPAD (currently running version 11) once I update it to version 12. I will give you a feedback in 1 hour approx.

Based on your initial findings, looks like SHA-1 is not accepted by Apple devices running version 12.

[Y C]

Maybe ios11 gives error but tolerates once hitting accept - but in ios12 it doesn't tolerate and makes you repeatedly have to accept?

[ajc]

I am actually interested on this post because we have over 40K Apple devices running EAP-TLS with the certificates deployed using MDM. That certificate is using SHA-1 because our internal CA Servers have not been moved to SHA-256 yet. Imagine if all the devices are suddenly update to version 12 and I start having those issues. I will get back to you as I said before. Give me a chance for testing.

[ajc]

Could you please post the ISE message when you get the repeated error?. I am wondering if something is registered on ISE.

[Y C]

The ISE auth succeeds... once you hit trust on the client device everything goes through normally.