WPA2-Enterprise w/ RADIUS Certificate/Trust Problem

Just because the root CA is the radius server, ("a very bad idea, by the way), the CLIENT connecting has no way or reason to trust the certificate being sent to encrypt the EAP traffic. If you don't deploy the root signing cert to the clients' root certificate store then this message is entirely expected.

I can make a separate server the root CA.

So, with Enterprise WPA, there is no way to get rid of that message? These are non-domain workstations connecting to the SSID, they just auth with domain credentials via RADIUS.

I guess the only trusted certs would come from 3rd party CA's? Which I cant use in my NPS policy since it requires a cert for the local server?

There are multiple ways to tackle the problem.  

You can create a deployment package that installs the cert and put it on an internet or extranet portal that employees can access before getting on the corporate wi-fi.

You can purchase a 3rd-party cert from a public CA. Not sure what you mean by "Which I cant use in my NPS policy since it requires a cert for the local server?"   If you properly managed the domain, this is a non-issue.

My personal preference and what I deploy as a consultant is to use an MDM to install certificates to BYOD devices:

I don't want some android device that jim-bob rooted and managed to pick up malware on my corporate network.  I don't want Becky-Sue's ancient windows XP laptop on my corporate network with all of the stuff it picked up since it left support.  Using a proper MDM solution to manage what BYOD devices can and can't have for compliance, and only deploying the certificate to "compliant" devices, and then only allowing those devices on the corpnet is usually a good thing.  

But any of the above are options to address the warning message.  And a warning message it is:   What is to stop a guy from installing windows server on his laptop, creating his own CA, propping up a powerful antenna that can basically drown out your weaker signal, broadcast the same SSID as your business with his own RADIUS server, and capture all of your users' internet traffic through his de-facto proxy that he can manipulate or spy on at will? If the certificate is untrusted, NOTHING prevents this.  Users can't distinguish between your untrusted certificate and his untrusted certificate.  It is a trivial war-driving tactic and allows all sorts of mayhem.  That's why the client, not just the RADIUS server, is supposed to trust the root, and why addressing this properly is important.

Could you elaborate on the 3rd party cert? We have an available SSL cert for wifi.externaldomain.edu but the internal server name is HAVOC.internaldomain.int

When connecting to the EWPA, it asks to trust the HAVOC.internaldomain.int which is why I made it a CA and selfsigned the cert. Are you saying I can use a 3rd party cert on my NPS/RADIUS server for full trust and get rid of the error entirely?

Yes. You can configure which certificate is used by NPS. It news not match the machine name at all.

I have installed the 3rd party cert into the certificate store, but have attached both screenshots of NPS here.

Is this the only change that needs to be made for all of my connection policies? I am setting this up in Network Policies -> Authentication policies
havoc.png
Capture.PNG

Note that the screen itself says what can override that setting.  If you have policies that override that setting then they would also need to be updated.