There is a lot of confusion around this on here, so I am making this post to be sure to understand it correctly. My school uses Aruba networks wifi, and after I type my Active Directory username and password (RADIUS authentication), it tells me I have to trust a certificate from 'wifiaruba.myschoolname.com' (Organization: My School) issued by DigiCert SHA2 High Assurance Server CA (Issuer Name, at least that is what the certificate says). I click trust and it goes away. My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications? If it really were from DigiCert, surely my phone would trust it?


It's ok. The certificate you installed and trusted is used to provide you secure authentication against their RADIUS server and prevent you from connecting to rogue RADIUS server. If someone decides to steal your Active Directory credentials by installing a rogue RADIUS server your phone will pop up with a warning that RADIUS certificate is not trusted.

By trusting this certificate you are not risking with anything else. This certificate can't be used by school to read your SSL traffic or attempt to MITM your SSL traffic. From what I read in your question, your school does it correctly and cares about your security.

Regarding your question: why your phone does not trust that certificate (which is certainly issued by trusted authority). RADIUS requires explicit trust to particular RADIUS authentication certificate, because you don't know what AP you are connecting to. Otherwise, an attacker could get certificate from other trusted CA vendor (say, Let's Encrypt) and use it to impersonate school RADIUS server and steal your credentials.

This is not an issue in SSL context, because you know what kind of certificate you expect, because you manually type web site name in address bar. In wi-fi don't know to which AP you are connected and to ensure that it is legitimate, AP should provide RADIUS certificate you explicitly trust.

  • Thanks! Can you tell me why my phone does not trust this current certificate? Surely something must be incorrectly configured no? – BusinessGuy Feb 1 '18 at 17:26
  • see my updated response. – Crypt32 Feb 1 '18 at 17:32
  • Thanks a lot! It seems like I have nothing to worry about :) – BusinessGuy Feb 1 '18 at 17:33
  • Two things, 1) The reason that the phone doesn't trust the Cert is probably because it'd signed by an Internal CA Managed by DigitCert, and since you don't have that issuer in your trusted connections yet, hence the ask. 2) This still doesn't prevent the school from MITIMing you. Network traffic could run through an SS/TLSL proxy and handle the interaction between the client and the Server. – Shane Andrie Feb 1 '18 at 18:01
  • "DigiCert SHA2 High Assurance Server CA" is not used in managed PKI scenarios. It is standard SSL CA server. Therefore it is not possible to MITM students. I explained in my answer why phone doesn't trust RADIUS cert even though CA is trusted. – Crypt32 Feb 1 '18 at 18:03

My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications?

Based on your description no it does not.

If it really were from DigiCert, surely my phone would trust it?

The problem is that before you authenticate to the wireless network, you are not actually connected to the network and can't reach any other host. When your device attempts to authenticate, the EAP supplicant on your phone will only be communicating with the authentication server.

With most EAP methods used by 802.11 wireless, the server will present a certificate to the EAP supplicant and the supplicant must make a decision if it will pass your credentials (username/password) back to the server. Since your device isn't yet connected to the network, the EAP supplicant is working with limited knowledge.

At the minimum, unless certificate validation is disabled, the EAP supplicant will check that the certificate is a valid certificate issued from a trusted CA and that the hostname listed on the certificate matches the hostname of the authentication server.

With some EAP supplicants, you can also optionally configure a designated CA(s) as the issuer of the certificate (i.e. only from Thawte or Digicert) and/or specific hostnames for the authentication servers. Many mobile devices (phones, tablets, etc) do not have these options.

Without use those options or some other sort of check, your phone would automatically accept any authentication server that would provide a valid certificate with a matching hostname. This would make it easy for an attacker to impersonate your school's wireless network and capture credentials on their own "authentication server." The prompt for you to accept the certificate is your chance to approve or reject sending your credentials to the authentication server.

Once you have accepted the certificate the first time, you should only ever see the prompt again if your phone is presented a different certificate (or you delete and re-add the wireless profile). Some schools will have multiple authentication servers so it isn't unusual to see this multiple times. However if you ever find a certificate suspicious (i.e. "arubuwifi.jimbobscomputers.com"), you should not accept it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.