Open extrafu opened 6 years ago
I believe we do this because of usage of self-signed certificates for the RADIUS server identity.
By installing the server certificate as the root, then only the server cert had to be bundled in the profile.
We could modify the mobileconfig based provisioners display to say that the certificate will be installed in the roots and changed the names to refer to the root cert instead of server cert.
In the meanwhile, we could simply use the CA instead of the server cert in the config and that should work
As mentioned in #5950, if you want clients to validate your RADIUS certificate, you just need to install CA certificate that signed RADIUS certificate. It's better to do that because if you have to renew RADIUS certificate, there is nothing to do on client side.
My proposal for this issue is to update provisioner code when doing EAP-PEAP to only include CA certificate.
Since merge of #5970, we now add CA certificate in mobileconfig with file by using a new field on Provisioner: RADIUS server CA path.
Android API >= 29 needs CN of RADIUS certificate so my previous proposal is not valid. However, this issue is still true, RADIUS certificate is still installed as Root using com.apple.security.root
PayloadType.
In order to fix this issue, we will need to do adjustments on Android and Windows agents and also check behavior on Apple devices.
When generating the mobile config profile for EAP-PEAP, we include the RADIUS server certificate and mark it as a root CA. That is likely wrong and we shouldn't do that. We should investigate why we are doing that and potentially remove this altogether.
An alternate possibility would be to allow CA file upload in PacketFence for EAP-PEAP and correctly include this so that we ask force RADIUS server certificate validation, we'll have the right CA to do so by including it in the mobile config profile.
That issue is related to this: https://github.com/inverse-inc/packetfence-windows-agent/issues/8