I have a customer where we acquired a public certificate to configure in the ClearPass Radius Server Certificate to not warning when the clients are connection to the network, since we have public clients.
We aquired the certificate from GoDaddy, and for Android and Windows we don't have any problem, but our clients with Iphone the connection is warning everytime with untrusted Certificate.
We validated the certificate, and also tried to generate a new certificate, but the problem persist only for Iphone.
We have others customer unsing certificate from GlobalSign and we don't have any problem.
How are the client authenticating - through the Guest captive portal or via 802.1X?
If you're using guest, there could be 2 reasons...
1) Apple doesn't natively trust the root certificate authority (probably unlikely as GoDaddy is common, but possible)
2) The captive portal redirect starts with navigation to an HTTPS site and since the gateway is acting as that site, it's seeing the certificate is not matching, once you bypass that, if the certificate is valid, the page should be successfully using HTTPS.
We've seen this happen when someone on Windows opens a browser and goes to google.com to force the redirect, even though we have a valid public certificate, it still displays a warning.
The warning is not in the HTTPs Certificate in the CaptivePortal, buti in the Radius Negotiation, this happen for 802.1x negotiation
But it`s a good question, the certificate configured for the Captive Portal is a wildcard Certificate from Godaddy and we don't have any warning for guest clients.
When you connect for the first time to a WPA Enterprise, if the Radius Certificate is a Private Certificate you will see a warning in the connection (after you put the credential), for this to not happen you can use a public certificate in the Radius Server Certificate or in the services certificate as the example bellow:
For others devices as Windows and Andoid this woks well, but for Iphone the warning is still happening as bellow:
This is not how it should work.
This is a negotiation happening in the radius negotiation, and the client should trust in the radius server cert since the client have the Root Certificate.For example, for the new Android 11 versions some manufacturers remove the option to ignore the certificate, so you is obligated to add the root Certificate to the trusted list tohe the Android connect to the network, and we solve this problem using a public certificate in the radius server.
This used to work with IPhone before, so what did apple change in they side to change this behavior?
Examplanation about the Radius TLS Tunnel Setup: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise
About the Radius Certificate, it's a requirement to have a trusted Certificate to not warning:
There are many server options available for RADIUS, which should work with MR access points if configured correctly. Please refer to your RADIUS server documentation for specifics, but the key requirements for WPA2-Enterprise with Meraki are as follows:
Once the RADIUS server is configured, refer to the Dashboard Configuration section below for instructions on how to add your RADIUS server to dashboard.
Think about it this way, if I were to buy a certificate from GoDaddy and setup a RADIUS server and broadcast an SSID just like yours, how would your client's know if it was your RADIUS server vs. mine they were sending their credentials to? The client is validating the server certificate, presumably something like "clearpass.<domain>.com", not just the Root CA. On Windows for example, to avoid the same certificate trust prompt, you would predefine the server name (CN from certificate) and select the Root CA in the trust list. That combination allows for it to trust the certificate and the server. In your case, the iPhone trusts the certificate, but still needs to verify the server is safe to send credentials to by means of that prompt. The only way I've seen to avoid this in our organization is to use an MDM solution where you can build a network profile and setup the trust before the device connects.
Additionally, while Windows and possibly Android offer the option to "not validate" the server certificate, I don't believe Apple offers the same due to their focus on security. Though, I'd have to dig more into the iPhone settings to be 100% positive of that.
I wonder if this is similar to a problem we seem to have developed with our CP captive portal. Mostly apple, but some Windows, clients can register their details to connect but at the point where they should be shown the 'client login' screen followed by the 'check you email' screen, they instead receive an error message because one way or another the device thinks it's not connected to the net. Even when two apple devices have the same trust store version (2022070700) one will connect and one won't. Proving very difficult to get to the bottom of this.
I seem to have got the bottom of our problem with certs and apple devices.It turned out that in the captive portal cert chain I'd created and uploaded to the controllers, the last cert in the chain, a root from Comodo, was using SHA1 and apple devices didn't like that and so complained/stopped clients connecting. I ended up removing that root cert, and the one before it in our chain, leaving only the public key, server cert, and the intermediate cert chained. The problem then went away.
Check using redkestrel
what MDM solution do you use? In my environment its normal to add the ClearPass DNS names as trusted in the wifi profile. This will prevent the users from accepting the radius cert manually.
AFAIK this is expected behaviour for Apple devices.
© Copyright 2024 Hewlett Packard Enterprise Development LPAll Rights Reserved.