Skip to main content

Hello everyone,



I've been working on getting 802.1x set up on our Macs using machine certificate authentication.



Currently, my configuration profile is set up such that all of the necessary domain certs are installed (CAs, and intermediate CAs) and trusted, an AD Certificate request is performed to get the machine certificate from the private CA, and a network payload is delivered specifying the SSID, WPA2 Enterprise as the authentication type, TLS as the protocol, and the machine AD Cert as the identity certificate.



If I leave the settings just like that and apply the configuration profile to a device, things work great for the most part. The user can connect to the wireless network by selecting it, specifying their device certificate for authentication, and confirming that they want to trust the certificate presented to them by the radius server.



This is the behavior that I would like to update. I don't trust the user to correctly identify and trust the certificate belonging to our radius server, and I don't want them sending their authentication attempt off to someone impersonating our SSID trying to MitM our network.



However, when I configure the trusted certificates setting on the configuration profile, things stop working. Under trusted certificates, I select our domain CA/intermediary certs, and I leave the allow trust exceptions box unchecked. This seems to be the exact thing that I want. But when deployed to a device, it is no longer able to connect, and the user is simply prompted over and over again to select their device certificate for authentication.



On a Microsoft forum I saw some people trying to achieve the same configuration I am saying that the only way they were able to get their policy to work is to leave all of the certificate trust settings blank, but I feel like that can't be right. Any thoughts on what may be going wrong here? It seems to me like the Mac for whatever reason is still not trusting the certificate presented to it by the radius server, even though it is issued by a CA in the trusted certificate settings, and a full chain of trust exists in the keychain.



Thanks for any help!
-Connor

If you're trying this on 10.12.5, you may want to read this thread .

I've had to install and trust the certificate chain the hard way, just using a package and manually installing/trusting them using security tool. See this link



It worked for me this way.

@AVmcclint So, I wasn't even on 10.12.5 on my test machine yet. There was a lot of interesting information in that thread, but I didn't see anything that seemed pertinent. General consensus seemed to be manually marking certs as trusted should do the trick, but it does not in my case.



@grahamfw That's how I was doing things initially. Deployed the certificates in a package and used a script to install them. I was just experimenting with moving the certificates into the configuration profile for the wireless network, that way I would be able to specify that the radius server should present a certificate from one of those CAs. Currently on my test machine, all of our certs are set to always trust, including in the eap section but wifi still won't connect if I specify trust settings in the configuration profile



I don't need to deploy a certificate from the radius server to the mac, right? As long as the certificate presented by the radius server comes from one of the trusted certificate authorities that I specify?



Seems really odd that if I don't put any trust settings in the config profile, you can connect to the network just fine (although the user has to affirm trust in the radius certificate), but if I specify that I only want to trust certificates signed by our domain ca things stop working, even though the radius server cert does come from the domain ca.

You might need to trust any intermediate certs as well. I had quite a time getting this to work at my last job.



If you can find an El Cap machine to test with, enable EAPOL debug and look at the certificate chain presented by the radius server to make sure that you're receiving what you think you are receiving. This will be in the debug logs and you'll need to break them into their own .pem certs and look at them with a command line util like openssl or keytool.



I'll see if I can find the instructions on how to do this in Sierra (can't find the pre-Sierra instructions anymore either...)

Just thought of another thing I had to do. In the Network Payload of the config profile, I added the RADIUS server certificate chain under "Trusted Server Certificate Names." These should be the common names of the certs that you've bundled in either the same profile or another one previously delivered. I believe that was the part that took me the longest to figure out.

Ok, just got everything figured out and working. My issue ended up being the same thing documented here , here , and here .



MacOs Sierra sees certificates that don't contain a subject name as being invalid (even though they aren't necessarily). The certificate that was being presented by my radius server had an empty subject name, so even though all of the necessary chain of trust was in place, the computer wouldn't trust it because it thinks its an invalid cert.



This is why when I didn't have any trust settings configured in jss and tried to connect to the AP, it would work, but I would be prompted to confirm trust in the server certificate every time I tried to connect, even if I told it to remember and always trust that certificate. When I tried to force it to trust certs that only come from our CA/intermediaries and didn't allow user exceptions, it could never connect because the device won't trust an invalid cert even if it is from a trusted CA.



To fix this issue, I requested a new certificate on the radius server from our ca that contained the subject name information. I then assigned this certificate to be used for incoming connection requests. On Microsoft NPS this is done by: NPS > Network Policies > Policy Properties > Constraints > Edit EAP Type > Certificate drop down box.

I'm not sure why Apple insists that empty subject is invalid despite being RFC compliant. I ran into the same issue with AD certs as well. Glad you got it figured out!



How did you end up seeing the certificate chain? Just in the certificate trust prompt?

@grahamfw Yeah, the certificate trust prompt on the client pc is how I was looking at it.

Reply


Terms & ConditionsCookie settings