Hello, We have several freeradius servers with a valid certificate for EAP. When the clients first log in via wifi, they are presented with a certificate "Not Trusted" warning, even though that certificate is signed by a trusted CA. Is this the expected behavior? Is this because we are missing a piece that is required by the client to trust this certificate? Awhile ago someone said that this should happen that the user should get the cert warning, thus this would occur every time the certificate is renewed. Cheers, - Trevor
On Wed, Jun 14, 2017 at 10:56:10AM -0400, Trevor Jennings wrote:
We have several freeradius servers with a valid certificate for EAP. When the clients first log in via wifi, they are presented with a certificate "Not Trusted" warning, even though that certificate is signed by a trusted CA. Is this the expected behavior?
Is this because we are missing a piece that is required by the client to trust this certificate?
Make sure the root CA for the server certificate is installed in the correct place on the client devices. Also, if they are running Windows, make sure you've also got the correct extension OIDs (e.g. TLS Web Server) in the server certificate. You shouldn't get a warning each time you connect or if you change the server certificate. -- Matthew
Thanks for the quick reply! We are using Thawte which Apple devices already trust (These are more common devices on our network). Are you referring to configuration profiles that are setup on the clients? Cheers, - Trevor On Wed, Jun 14, 2017 at 11:01 AM, Matthew Newton < matthew@newtoncomputing.co.uk> wrote:
On Wed, Jun 14, 2017 at 10:56:10AM -0400, Trevor Jennings wrote:
We have several freeradius servers with a valid certificate for EAP. When the clients first log in via wifi, they are presented with a certificate "Not Trusted" warning, even though that certificate is signed by a trusted CA. Is this the expected behavior?
Is this because we are missing a piece that is required by the client to trust this certificate?
Make sure the root CA for the server certificate is installed in the correct place on the client devices.
Also, if they are running Windows, make sure you've also got the correct extension OIDs (e.g. TLS Web Server) in the server certificate.
You shouldn't get a warning each time you connect or if you change the server certificate.
-- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Jun 14, 2017, at 11:19 AM, Trevor Jennings <Trevor@simple101.com> wrote:
We are using Thawte which Apple devices already trust (These are more common devices on our network).
Do not use public CA certs for WiFi authentication. It's insecure. And no, the Apple devices do NOT already trust the Thawte cert for WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different. You need to have a mobileconfig which tells each device what the SSID is, what EAP method to use, and what CA to use.
Are you referring to configuration profiles that are setup on the clients?
Yes. You need to configure each device as I said above. In order to get EAP working, follow the guide at: http://deployingradius.com/documents/configuration/eap.html It WILL work. And yes, it involves creating your own certificates, and also installing the certificates on the clients. Alan DeKok.
You will receive the prompt the first time a new device connects to that SSID. You should really pre-configure the clients or you’re putting the user’s credentials at risk. On 6/14/17, 11:39 AM, "Freeradius-Users on behalf of Alan DeKok" <freeradius-users-bounces+timc=hpe.com@lists.freeradius.org on behalf of aland@deployingradius.com> wrote: On Jun 14, 2017, at 11:19 AM, Trevor Jennings <Trevor@simple101.com> wrote: > > We are using Thawte which Apple devices already trust (These are more > common devices on our network). Do not use public CA certs for WiFi authentication. It's insecure. And no, the Apple devices do NOT already trust the Thawte cert for WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different. You need to have a mobileconfig which tells each device what the SSID is, what EAP method to use, and what CA to use. > Are you referring to configuration profiles that are setup on the clients? Yes. You need to configure each device as I said above. In order to get EAP working, follow the guide at: http://deployingradius.com/documents/configuration/eap.html It WILL work. And yes, it involves creating your own certificates, and also installing the certificates on the clients. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
You will receive the prompt the first time a new device connects to that SSID. You should really pre-configure the clients or you’re putting the user’s credentials at risk.
Exactly. For a longer treatise on the subject: https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+consideratio... (applicability not limited to eduroam) If the OP is doing this for an eduroam installation, said pre-configuration profiles can be built at https://cat.eduroam.org If this is not about eduroam, there are plenty of commercial solutions. A freemium one is https://802.1x-config.org Greetings, Stefan Winter
On 6/14/17, 11:39 AM, "Freeradius-Users on behalf of Alan DeKok" <freeradius-users-bounces+timc=hpe.com@lists.freeradius.org on behalf of aland@deployingradius.com> wrote:
On Jun 14, 2017, at 11:19 AM, Trevor Jennings <Trevor@simple101.com> wrote: > > We are using Thawte which Apple devices already trust (These are more > common devices on our network).
Do not use public CA certs for WiFi authentication. It's insecure.
And no, the Apple devices do NOT already trust the Thawte cert for WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different.
You need to have a mobileconfig which tells each device what the SSID is, what EAP method to use, and what CA to use.
> Are you referring to configuration profiles that are setup on the clients?
Yes. You need to configure each device as I said above.
In order to get EAP working, follow the guide at:
http://deployingradius.com/documents/configuration/eap.html
It WILL work.
And yes, it involves creating your own certificates, and also installing the certificates on the clients.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Thanks for those links Stefan. We do have both eduroam and our own internal auth. Cheers, - Trevor On Thu, Jun 15, 2017 at 1:52 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
You will receive the prompt the first time a new device connects to that SSID. You should really pre-configure the clients or you’re putting the user’s credentials at risk.
Exactly. For a longer treatise on the subject:
https://wiki.geant.org/display/H2eduroam/EAP+Server+ Certificate+considerations
(applicability not limited to eduroam)
If the OP is doing this for an eduroam installation, said pre-configuration profiles can be built at
If this is not about eduroam, there are plenty of commercial solutions. A freemium one is
Greetings,
Stefan Winter
On 6/14/17, 11:39 AM, "Freeradius-Users on behalf of Alan DeKok"
<freeradius-users-bounces+timc=hpe.com@lists.freeradius.org on behalf of aland@deployingradius.com> wrote:
On Jun 14, 2017, at 11:19 AM, Trevor Jennings <Trevor@simple101.com>
wrote:
> > We are using Thawte which Apple devices already trust (These are
more
> common devices on our network).
Do not use public CA certs for WiFi authentication. It's insecure.
And no, the Apple devices do NOT already trust the Thawte cert for
WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different.
You need to have a mobileconfig which tells each device what the
SSID is, what EAP method to use, and what CA to use.
> Are you referring to configuration profiles that are setup on the
clients?
Yes. You need to configure each device as I said above.
In order to get EAP working, follow the guide at:
http://deployingradius.com/documents/configuration/eap.html
It WILL work.
And yes, it involves creating your own certificates, and also
installing the certificates on the clients.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/
list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/
list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette
Tel: +352 424409 1 Fax: +352 422473
PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Thanks for the replies! We've had EAP functioning well for the past 7-8 years and when the cert comes up to renew, I've been asked why do we need to keep trusting the certificate, so I am trying to find answers.
Do not use public CA certs for WiFi authentication. It's insecure.
So you are suggesting we should be using self signed certs instead of a public CA?
And no, the Apple devices do NOT already trust the Thawte cert for WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different.
This is what I do not understand. The root certificate is the same for both and is sent as part of the EAP process along with the server certificate. I know this sounds like a stupid question but how are these both different?
You need to have a mobileconfig which tells each device what the SSID is, what EAP method to use, and what CA to use.
Are you referring to configuration profiles that are setup on the clients?
Yes. You need to configure each device as I said above.
I understand this as when I receive the new certificate, I send it along to service desk who setup profiles on staff/faculty machines that use WiFi. I think they also may use MDM to send the profiles to mobiles, but only some staff/faculty devices.
In order to get EAP working, follow the guide at:
http://deployingradius.com/documents/configuration/eap.html
It WILL work.
And yes, it involves creating your own certificates, and also installing the certificates on the clients.
It sounds like we should provide a solution to allow clients to install the certificates. Cheers, - Trevor
On Jun 15, 2017, at 1:42 PM, Trevor Jennings <Trevor@simple101.com> wrote:
We've had EAP functioning well for the past 7-8 years and when the cert comes up to renew, I've been asked why do we need to keep trusting the certificate, so I am trying to find answers.
You need to keep trusting the cert, because if you don't trust it, you shouldn't use it for anything.
Do not use public CA certs for WiFi authentication. It's insecure.
So you are suggesting we should be using self signed certs instead of a public CA?
It's generally safer. For many reasons outlined earlier. Most end-user systems now do "server cert pinning". This means that they keep a copy of the server cert on first successful authentication. They then refuse to connect if the server cert changes. It's not part of the specs, but it's arguably better than nothing.
And no, the Apple devices do NOT already trust the Thawte cert for WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different.
This is what I do not understand. The root certificate is the same for both and is sent as part of the EAP process along with the server certificate. I know this sounds like a stupid question but how are these both different?
EAP is different from HTTPS. That's the short answer. The longer answer is that EAP has a very different use-case than HTTPS. For HTTPS, you want to ensure that the web site you're connecting to is "known". i.e. trusted by the CA. But you are NOT giving it your password. You're downloading their web site. For EAP, you're not downloading data. You're handing the server your password. So you want to be sure that you're handing the password to the *correct* server. i.e. as server you know. Not a random server which is trusted by the CA. Do you "trust" both gmail and Microsoft enough to download web pages from them? Likely yes. Would you hand your gmail account passwords to Microsoft? Likely not. That's the difference. Alan DeKok.
Thank you for that explanation. That has helped a lot to understand the difference between the EAP and HTTPS certificate process and why private signed is better than the public signed CA. Cheers, - Trevor On Thu, Jun 15, 2017 at 2:14 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 15, 2017, at 1:42 PM, Trevor Jennings <Trevor@simple101.com> wrote:
We've had EAP functioning well for the past 7-8 years and when the cert comes up to renew, I've been asked why do we need to keep trusting the certificate, so I am trying to find answers.
You need to keep trusting the cert, because if you don't trust it, you shouldn't use it for anything.
Do not use public CA certs for WiFi authentication. It's insecure.
So you are suggesting we should be using self signed certs instead of a public CA?
It's generally safer. For many reasons outlined earlier.
Most end-user systems now do "server cert pinning". This means that they keep a copy of the server cert on first successful authentication. They then refuse to connect if the server cert changes.
It's not part of the specs, but it's arguably better than nothing.
And no, the Apple devices do NOT already trust the Thawte cert for WiFi authentication. They trust the Thawte cert for web surfing, which is entirely different.
This is what I do not understand. The root certificate is the same for both and is sent as part of the EAP process along with the server certificate. I know this sounds like a stupid question but how are these both different?
EAP is different from HTTPS.
That's the short answer.
The longer answer is that EAP has a very different use-case than HTTPS. For HTTPS, you want to ensure that the web site you're connecting to is "known". i.e. trusted by the CA. But you are NOT giving it your password. You're downloading their web site.
For EAP, you're not downloading data. You're handing the server your password. So you want to be sure that you're handing the password to the *correct* server. i.e. as server you know. Not a random server which is trusted by the CA.
Do you "trust" both gmail and Microsoft enough to download web pages from them? Likely yes.
Would you hand your gmail account passwords to Microsoft? Likely not.
That's the difference.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
participants (6)
-
Alan DeKok -
Cappalli, Tim (Aruba Security) -
Matthew Newton -
Stefan Winter -
Trevor Jennings -
Trevor Jennings