Re: [WIRELESS-LAN] Certificate for 802.1x

[Travis Schick]

You can use the same cert on multiple servers, but each server will then
need to use the same key.

I use openssl to create a key and then create csr - you can then package
key with cert and any interim certs needed into a single file to be
imported on each server.

If you use the csr tool builtin to some interfaces - they will use a
locally created key.   If you can export from your first server with
private key - you should be able to import that into your other servers.

Order of certs shouldn't be an issue - but some OS's are picky, ie windows
vista business 64
I've been using this order in a single PEM file that I import on my
clearpass servers.

server cert
private key
interim cert(s)
root cert



I suppose in theory one could leave off the root - as the OS should have it
in the trust store already - but have not tested that - potentially
optimize the auth I mean fewer bits is less airtime used especially as
mobile devices auth quite a bit

 I would be interested if anyone has tested/done this with success

-Travis

On Mon, Mar 20, 2017 at 9:43 AM Eric Glinsky <eglin...@woodstockacademy.org>
wrote:

> Thanks for the info, guys! It seems that “it is what it is” after all.
>
>
>
> Still haven’t had a chance to try the third-party CA with Win7 to decide
> if it’s worth keeping.
>
>
>
> From what’s been discussed, I should be able to use the same cert across
> multiple RADIUS servers. No luck so far. On our first RADIUS server, I set
> up authentication with a cert issued to the host’s FQDN, with the domain CA
> (which also happens to be the RADIUS server) as the issuer. I tried
> exporting the cert from the original RADIUS server and importing it to the
> secondary server, but clients fail to authenticate. Any suggestions, such
> as file format, also exporting the root cert or not (with or without
> private key), etc. would be appreciated. Please forgive me if I’m totally
> off base since I have very limited experience with certs! J
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Kevin Fitzgerald
> *Sent:* Monday, March 13, 2017 3:15 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>
>
> *Subject:* Re: [WIRELESS-LAN] Certificate for 802.1x
>
>
>
> Hi Eric,
>
>
>
> From what I understand, the reason that even 3rd party certificates fail
> is that the clients do not have a trusted radius store as they do with
> SSL.  That is to say, by default, most clients will not trust any radius
> certificate regardless of the issuer.
>
>
>
> Some vendors provide an on-boarding module that distributes the trust
> parameters to the client as a workaround to the above.
>
>
>
> Kevin
>
>
>
> On Mon, Mar 13, 2017 at 2:10 PM, Eric Glinsky <
> eglin...@woodstockacademy.org> wrote:
>
> Hi everyone,
>
>
>
> I’m looking for thoughts/opinions/experiences on 802.1x and security
> certificates. I dug through the archives from a few years ago, and from
> what I gather it isn’t even possible to use a 3rd-party cert so devices
> (iOS, OS X, Windows, Android) trust it automatically, but maybe someone has
> succeeded with this by now? If so, which CA would you recommend?
>
>
>
> For us, our GoDaddy wildcard cert failed to authenticate clients, so we
> went with DigiCert. That isn’t trusted by clients by default, offering no
> benefit over our domain-generated cert, with which all Apple and Windows
> 8/10 devices must be told to “trust,” Windows 7 fails to authenticate
> entirely, and Android just works. We have a Cisco WLC and Windows NPS.
>
>
>
> Thanks for any pointers you can give!
>
>
>
> - Eric
>
> This e-mail message is intended only for the person or entity to which it
> is addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender and destroy all
> copies of the original message. If you are the intended recipient but do
> not wish to receive communications through this medium, please so advise
> the sender immediately.
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/discuss.
>
>
>
>
>
> --
>
> Kevin Fitzgerald | Project/Program Specialist
> University of Arkansas at Little Rock | Information Technology Services
> 501.916.5019 <(501)%20916-5019> | kwfitzger...@ualr.edu | ualr.edu
>
>
>
> Reminder: IT Services will never ask for your password over the phone or
> in an email. Always be suspicious of requests for personal information that
> comes via e

Re: [WIRELESS-LAN] Certificate for 802.1x

[Mike King]

I'm pretty sure you will need the Private key.

On Mon, Mar 20, 2017 at 12:34 PM, Eric Glinsky <
eglin...@woodstockacademy.org> wrote:

> Thanks for the info, guys! It seems that “it is what it is” after all.
>
>
>
> Still haven’t had a chance to try the third-party CA with Win7 to decide
> if it’s worth keeping.
>
>
>
> From what’s been discussed, I should be able to use the same cert across
> multiple RADIUS servers. No luck so far. On our first RADIUS server, I set
> up authentication with a cert issued to the host’s FQDN, with the domain CA
> (which also happens to be the RADIUS server) as the issuer. I tried
> exporting the cert from the original RADIUS server and importing it to the
> secondary server, but clients fail to authenticate. Any suggestions, such
> as file format, also exporting the root cert or not (with or without
> private key), etc. would be appreciated. Please forgive me if I’m totally
> off base since I have very limited experience with certs! J
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Kevin Fitzgerald
> *Sent:* Monday, March 13, 2017 3:15 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Certificate for 802.1x
>
>
>
> Hi Eric,
>
>
>
> From what I understand, the reason that even 3rd party certificates fail
> is that the clients do not have a trusted radius store as they do with
> SSL.  That is to say, by default, most clients will not trust any radius
> certificate regardless of the issuer.
>
>
>
> Some vendors provide an on-boarding module that distributes the trust
> parameters to the client as a workaround to the above.
>
>
>
> Kevin
>
>
>
> On Mon, Mar 13, 2017 at 2:10 PM, Eric Glinsky <
> eglin...@woodstockacademy.org> wrote:
>
> Hi everyone,
>
>
>
> I’m looking for thoughts/opinions/experiences on 802.1x and security
> certificates. I dug through the archives from a few years ago, and from
> what I gather it isn’t even possible to use a 3rd-party cert so devices
> (iOS, OS X, Windows, Android) trust it automatically, but maybe someone has
> succeeded with this by now? If so, which CA would you recommend?
>
>
>
> For us, our GoDaddy wildcard cert failed to authenticate clients, so we
> went with DigiCert. That isn’t trusted by clients by default, offering no
> benefit over our domain-generated cert, with which all Apple and Windows
> 8/10 devices must be told to “trust,” Windows 7 fails to authenticate
> entirely, and Android just works. We have a Cisco WLC and Windows NPS.
>
>
>
> Thanks for any pointers you can give!
>
>
>
> - Eric
>
> This e-mail message is intended only for the person or entity to which it
> is addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender and destroy all
> copies of the original message. If you are the intended recipient but do
> not wish to receive communications through this medium, please so advise
> the sender immediately.
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
>
>
>
>
>
> --
>
> Kevin Fitzgerald | Project/Program Specialist
> University of Arkansas at Little Rock | Information Technology Services
> 501.916.5019 <(501)%20916-5019> | kwfitzger...@ualr.edu | ualr.edu
>
>
>
> Reminder: IT Services will never ask for your password over the phone or
> in an email. Always be suspicious of requests for personal information that
> comes via email, even from known contacts. For more information or to
> report suspicious email, visit http://ualr.edu/itservices/security/
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
> This e-mail message is intended only for the person or entity to which it
> is addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender and destroy all
> copies of the original message. If you are the intended recipient but do
> not wish to receive communications through this medium, please so advise
> the sender immediately. This e-mail message is intended only for the person
> or entity to which it is addressed and may contain CONFIDENTIAL or
> PRIVILEGED material. Any unauthorized review, use, disclosure or

RE: [WIRELESS-LAN] Certificate for 802.1x

[Eric Glinsky]

Thanks for the info, guys! It seems that “it is what it is” after all.

Still haven’t had a chance to try the third-party CA with Win7 to decide if 
it’s worth keeping.

From what’s been discussed, I should be able to use the same cert across 
multiple RADIUS servers. No luck so far. On our first RADIUS server, I set up 
authentication with a cert issued to the host’s FQDN, with the domain CA (which 
also happens to be the RADIUS server) as the issuer. I tried exporting the cert 
from the original RADIUS server and importing it to the secondary server, but 
clients fail to authenticate. Any suggestions, such as file format, also 
exporting the root cert or not (with or without private key), etc. would be 
appreciated. Please forgive me if I’m totally off base since I have very 
limited experience with certs! ☺


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kevin Fitzgerald
Sent: Monday, March 13, 2017 3:15 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Certificate for 802.1x

Hi Eric,

From what I understand, the reason that even 3rd party certificates fail is 
that the clients do not have a trusted radius store as they do with SSL.  That 
is to say, by default, most clients will not trust any radius certificate 
regardless of the issuer.

Some vendors provide an on-boarding module that distributes the trust 
parameters to the client as a workaround to the above.

Kevin

On Mon, Mar 13, 2017 at 2:10 PM, Eric Glinsky 
<eglin...@woodstockacademy.org<mailto:eglin...@woodstockacademy.org>> wrote:
Hi everyone,

I’m looking for thoughts/opinions/experiences on 802.1x and security 
certificates. I dug through the archives from a few years ago, and from what I 
gather it isn’t even possible to use a 3rd-party cert so devices (iOS, OS X, 
Windows, Android) trust it automatically, but maybe someone has succeeded with 
this by now? If so, which CA would you recommend?

For us, our GoDaddy wildcard cert failed to authenticate clients, so we went 
with DigiCert. That isn’t trusted by clients by default, offering no benefit 
over our domain-generated cert, with which all Apple and Windows 8/10 devices 
must be told to “trust,” Windows 7 fails to authenticate entirely, and Android 
just works. We have a Cisco WLC and Windows NPS.

Thanks for any pointers you can give!

- Eric
This e-mail message is intended only for the person or entity to which it is 
addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender and destroy all copies of the 
original message. If you are the intended recipient but do not wish to receive 
communications through this medium, please so advise the sender immediately.
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.



--
Kevin Fitzgerald | Project/Program Specialist
University of Arkansas at Little Rock | Information Technology Services
501.916.5019 | kwfitzger...@ualr.edu<mailto:kwfitzger...@ualr.edu> | 
ualr.edu<http://ualr.edu>

Reminder: IT Services will never ask for your password over the phone or in an 
email. Always be suspicious of requests for personal information that comes via 
email, even from known contacts. For more information or to report suspicious 
email, visit http://ualr.edu/itservices/security/
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.
This e-mail message is intended only for the person or entity to which it is 
addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender and destroy all copies of the 
original message. If you are the intended recipient but do not wish to receive 
communications through this medium, please so advise the sender immediately. 
This e-mail message is intended only for the person or entity to which it is 
addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender and destroy all copies of the 
original message. If you are the intended recipient but do not wish to receive 
communications through this medium, please so advise the sender immediately.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Certificate for 802.1x

[Travis Schick]

Hmm tempted to create my own signing authority cert and create one with
expiration way into the future  though I just know if I do that - next
week we'll find out that we can't use SHA-2 anymore - or any keys less than
8192 bits are too small

So until that quantum cryptography stuph gets sorted out to stop all chance
of man in the middle  I think the best option is :

use one cert for all radius servers - use a server name that is simple -
have scheduled and well announced cert updates when needed.


So far we have gone through a few cert changes - and its pain - but
scheduling them after our spring session ends and before summer sessions
helps.   So outgoing students don't necessarily need to care early into
the summer for any prospective students to get proper certs via eduroam CAT
tool.   Also having the date set ahead of time - gets support staff ready
and allows for communication to go out...  so hopefully when prompted a
student knows why - what to look for and life with wifi continues
 (possibly a few weeks with increased captive portal ssid usage)

Ultimately it comes to education - as much as we want devices to just
auto-magically connect securely without prompting the user - even with
provisioning tools the user gets prompted to trust something - just not
enough data to auto-trust.  So they need to know what to trust.

Also keep the setup as simple as possible.   We use a single cert on all
our radius servers  with a simple name to look for eap. - publish
the digest and the cert so security minded folks can verify - or download
and install via other means.

Our university is under InCommon - so cost of public CA signed certs is not
an issue for me.  I like to see that I'm getting prompted to trust a valid
cert - even if the OS won't be able to verify it  - yes I still have to
answer questions - why it prompts -"you guys should order certs via godaddy
- my web server never asks me..."
*sigh*



-Travis

On Tue, Mar 14, 2017 at 6:40 AM Jethro R Binks 
wrote:

> On Mon, 13 Mar 2017, Oakes, Carl W wrote:
>
> > This one hits home for me, going through this now on a certificate
> > expiring and battling on what to do next.
> >
> > Most clients don't trust any certificate, even if the device is set to
> > trust them OS wide (web browser, etc).  The wireless / supplicant
> > configuration needs to be setup to trust specific certs or CA's.
> >
> > Onboarding tools can be used like SecureW2, Aruba , Cloudpath,
> > eduroam CAT to load and enable the RADIUS cert and set it
> > active/trusted.
> >
> > If clients onboard themselves, just by manually attaching to the
> > network, they trust the immediate certificate, and I think in some
> > cases, just the digest of the cert, making future cert updates
> > "eventful".
> >
> > Clients when authenticating can't check the CRL or OCSP for certificate
> > revocation, since they aren't on the network yet while trying to
> > authenticate.
> >
> > So, with all that, I really don't want to get another 3 or 4 year cert
> > and deal with the expiring cert again.  Not a pretty scenario. Last time
> > this happened, it hit us by surprise since we couldn't get a new cert
> > based on the previously trusted CA.  E
> >
> > I'm tempted to create a self-signed local CA just for the RADIUS server
> > validation, and a then generate a single cert off that CA.  Then have
> > SecureW2 (what we have) provide that CA and mark it as trusted. Since
> > it's our own CA, was going to make it good for 20 years (just shy of the
> > 2038 unix time clock issue).  Avoids the problem until after I retire.
> > :)
> >
> > In testing, so far this seems to work great.  But test is very different
> > than thousands of random student devices.
> >
> > In theory it could be just a single self-signed cert, but I liked have
> > the added bonus / flexibility / futures of the self-signed CA just in
> > case.
> >
> > Either way, if the private key of the RAIDUS cert gets compromised
> > (commercial or self-signed), it's a world of hurt to get folks moved
> > over in a secure way.
> >
> > Has anyone done this?  Good or bad? Am I missing anything key?
> >
> > Next up will be client based certs, but that doesn't fix/resolve the
> > above issue.
>
> (Not at all a cert expert, but this is a dump of my experience from a
> while back).
>
> This is what we did, in advance of our commercial cert expiry about 18
> months ago.
>
> Create local root cert with a looong life.  Allow it to issues certs.
>
> Create cert in the name of the radius server.  Doesn't have to relate to
> the DNS name of the server or anything else, just as long as the server
> presents it, and the client is configured to trust the name in it.
>
> You can share the single cert amongst the radius servers.
>
> Use eduroam CAT onboarding to install root cert (and intermediates if you
> have them).
>
> So then, as long as the client knows the (long lived) root, and is
> configured to trust the 

Re: [WIRELESS-LAN] Certificate for 802.1x

[Jethro R Binks]

On Mon, 13 Mar 2017, Oakes, Carl W wrote:

> This one hits home for me, going through this now on a certificate 
> expiring and battling on what to do next.
> 
> Most clients don't trust any certificate, even if the device is set to 
> trust them OS wide (web browser, etc).  The wireless / supplicant 
> configuration needs to be setup to trust specific certs or CA's.
> 
> Onboarding tools can be used like SecureW2, Aruba , Cloudpath, 
> eduroam CAT to load and enable the RADIUS cert and set it 
> active/trusted.
> 
> If clients onboard themselves, just by manually attaching to the 
> network, they trust the immediate certificate, and I think in some 
> cases, just the digest of the cert, making future cert updates 
> "eventful".
> 
> Clients when authenticating can't check the CRL or OCSP for certificate 
> revocation, since they aren't on the network yet while trying to 
> authenticate.
> 
> So, with all that, I really don't want to get another 3 or 4 year cert 
> and deal with the expiring cert again.  Not a pretty scenario. Last time 
> this happened, it hit us by surprise since we couldn't get a new cert 
> based on the previously trusted CA.  E
> 
> I'm tempted to create a self-signed local CA just for the RADIUS server 
> validation, and a then generate a single cert off that CA.  Then have 
> SecureW2 (what we have) provide that CA and mark it as trusted. Since 
> it's our own CA, was going to make it good for 20 years (just shy of the 
> 2038 unix time clock issue).  Avoids the problem until after I retire. 
> :)
> 
> In testing, so far this seems to work great.  But test is very different 
> than thousands of random student devices.
> 
> In theory it could be just a single self-signed cert, but I liked have 
> the added bonus / flexibility / futures of the self-signed CA just in 
> case.
> 
> Either way, if the private key of the RAIDUS cert gets compromised 
> (commercial or self-signed), it's a world of hurt to get folks moved 
> over in a secure way.
> 
> Has anyone done this?  Good or bad? Am I missing anything key?
> 
> Next up will be client based certs, but that doesn't fix/resolve the 
> above issue.

(Not at all a cert expert, but this is a dump of my experience from a 
while back).

This is what we did, in advance of our commercial cert expiry about 18 
months ago.

Create local root cert with a looong life.  Allow it to issues certs.

Create cert in the name of the radius server.  Doesn't have to relate to 
the DNS name of the server or anything else, just as long as the server 
presents it, and the client is configured to trust the name in it.

You can share the single cert amongst the radius servers.

Use eduroam CAT onboarding to install root cert (and intermediates if you 
have them).

So then, as long as the client knows the (long lived) root, and is 
configured to trust the server name, and the server presents a certificate 
featuring that name (in both CN and subjectAltName), future cert rollovers 
are trivial (modulo your comment about client storing a digest). But if 
you're self-signing, you can make it as long as you like I guess.

We tested in our RADIUS server by having a separate clause based on 
calling-station MAC to divert to the "new" cert.

In advance of the changeover, we created a new CAT profile that had both 
the current cert and the new ones, so we were seeding the new certs for 
some time before (not long enough to be honest - if you know you have a 
cert changeover to perform, plan early early early!).  Android was a pain 
as it didn't like that and wouldn't install both so they had to be left 
until cert-change-D-day to reconfigure.

Sometimes Windows machines wouldn't take it directly either and you had to 
manually do it (vague memories).

You do have to be careful setting some of the parameters on the certs/etc 
and follow good recommendations for key lengths and ciphers and so on. 
There's some information on the eduroam site I think.

I used openssl.  The following was useful, according to my notes, and 
possibly other pages off that:  
https://www.phildev.net/ssl/creating_ca.html

I still have the bits of scripts and openssl.cnf files somewhere.

To recap what might have already been said here and certainly elsewhere: a 
commercial cert for radius servers provides no additional benefit, since 
there is no way for the client to verify the cert other than by how you're 
going to configure it anyway.  In the web browser case, the server is 
comparing the name in the cert with the domain name in the https://, and 
considering if they match up, to provide an assurance you are talking to 
the correct end point and aren't being MITM'd.  In the Radius case, you 
have to onboard the clients anyway to put the certs in there, and (if 
following best practices) tell them which radius servers to trust.  Since 
you're doing that anyway, you can install a matching cert to your own 
specification so why pay $$$ for something that's going to give you pain 

Re: [WIRELESS-LAN] Certificate for 802.1x

[Cappalli, Tim (Aruba)]

One trick with configuring clients: You can configure the client with common 
name validation and then validate the root CA. When you have to renew the 
certificate, users *shouldn’t* receive any messages because the validation 
information in the supplicant remains the same.

The ideal solution is to move to EAP-TLS and move away from legacy protocols 
like PEAPv0 and EAP-TTLS that have known issues and security concerns.


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "Oakes, Carl W" 
<oake...@csus.edu>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Monday, March 13, 2017 at 3:42 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Certificate for 802.1x

This one hits home for me, going through this now on a certificate expiring and 
battling on what to do next.

Most clients don't trust any certificate, even if the device is set to trust 
them OS wide (web browser, etc).  The wireless / supplicant configuration needs 
to be setup to trust specific certs or CA's.

Onboarding tools can be used like SecureW2, Aruba , Cloudpath, eduroam CAT 
to load and enable the RADIUS cert and set it active/trusted.

If clients onboard themselves, just by manually attaching to the network, they 
trust the immediate certificate, and I think in some cases, just the digest of 
the cert, making future cert updates "eventful".

Clients when authenticating can't check the CRL or OCSP for certificate 
revocation, since they aren't on the network yet while trying to authenticate.

So, with all that, I really don't want to get another 3 or 4 year cert and deal 
with the expiring cert again.Not a pretty scenario.
Last time this happened, it hit us by surprise since we couldn't get a new cert 
based on the previously trusted CA.  E

I'm tempted to create a self-signed local CA just for the RADIUS server 
validation, and a then generate a single cert off that CA.   Then have SecureW2 
(what we have) provide that CA and mark it as trusted.
Since it's our own CA, was going to make it good for 20 years (just shy of the 
2038 unix time clock issue).Avoids the problem until after I retire. :)

In testing, so far this seems to work great.But test is very different than 
thousands of random student devices.

In theory it could be just a single self-signed cert, but I liked have the 
added bonus / flexibility / futures of the self-signed CA just in case.

Either way, if the private key of the RAIDUS cert gets compromised (commercial 
or self-signed), it's a world of hurt to get folks moved over in a secure way.

Has anyone done this?  Good or bad? Am I missing anything key?

Next up will be client based certs, but that doesn't fix/resolve the above 
issue.

Carl Oakes
California State University Sacramento




From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Glinsky
Sent: Monday, March 13, 2017 12:11 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Certificate for 802.1x

Hi everyone,

I’m looking for thoughts/opinions/experiences on 802.1x and security 
certificates. I dug through the archives from a few years ago, and from what I 
gather it isn’t even possible to use a 3rd-party cert so devices (iOS, OS X, 
Windows, Android) trust it automatically, but maybe someone has succeeded with 
this by now? If so, which CA would you recommend?

For us, our GoDaddy wildcard cert failed to authenticate clients, so we went 
with DigiCert. That isn’t trusted by clients by default, offering no benefit 
over our domain-generated cert, with which all Apple and Windows 8/10 devices 
must be told to “trust,” Windows 7 fails to authenticate entirely, and Android 
just works. We have a Cisco WLC and Windows NPS.

Thanks for any pointers you can give!

- Eric
This e-mail message is intended only for the person or entity to which it is 
addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender and destroy all copies of the 
original message. If you are the intended recipient but do not wish to receive 
communications through this medium, please so advise the sender immediately.
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Certificate for 802.1x

[Kevin Fitzgerald]

Hi Eric,

>From what I understand, the reason that even 3rd party certificates fail is
that the clients do not have a trusted radius store as they do with SSL.
That is to say, by default, most clients will not trust any radius
certificate regardless of the issuer.

Some vendors provide an on-boarding module that distributes the trust
parameters to the client as a workaround to the above.

Kevin

On Mon, Mar 13, 2017 at 2:10 PM, Eric Glinsky  wrote:

> Hi everyone,
>
>
>
> I’m looking for thoughts/opinions/experiences on 802.1x and security
> certificates. I dug through the archives from a few years ago, and from
> what I gather it isn’t even possible to use a 3rd-party cert so devices
> (iOS, OS X, Windows, Android) trust it automatically, but maybe someone has
> succeeded with this by now? If so, which CA would you recommend?
>
>
>
> For us, our GoDaddy wildcard cert failed to authenticate clients, so we
> went with DigiCert. That isn’t trusted by clients by default, offering no
> benefit over our domain-generated cert, with which all Apple and Windows
> 8/10 devices must be told to “trust,” Windows 7 fails to authenticate
> entirely, and Android just works. We have a Cisco WLC and Windows NPS.
>
>
>
> Thanks for any pointers you can give!
>
>
>
> - Eric
> This e-mail message is intended only for the person or entity to which it
> is addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender and destroy all
> copies of the original message. If you are the intended recipient but do
> not wish to receive communications through this medium, please so advise
> the sender immediately.
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
>
>


-- 
Kevin Fitzgerald | Project/Program Specialist
University of Arkansas at Little Rock | Information Technology Services
501.916.5019 | kwfitzger...@ualr.edu | ualr.edu

Reminder: IT Services will never ask for your password over the phone or in
an email. Always be suspicious of requests for personal information that
comes via email, even from known contacts. For more information or to
report suspicious email, visit http://ualr.edu/itservices/security/

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Certificate for 802.1x

[Cappalli, Tim (Aruba)]

Couple of things


-   Wildcard and EV certificates should never be used for RADIUS

-   Keep in mind that EAP server certificate trust is different than system 
level certificate trust.

o   Even with a public certificate,  you will still receive a certificate 
prompt on initial connection if the client has not been manually configured

o   The common name of the RADIUS server certificate does NOT need to have a 
DNS entry, it’s “visual” only.

-   A standard “generic” web server certificate from any of the major 
providers will work. I always recommend using a user friendly name for the 
common name like wireless.domain.xyz or network-login.domain.xyz since users 
will see it.

tim

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Eric Glinsky 
<eglin...@woodstockacademy.org>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Monday, March 13, 2017 at 3:10 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Certificate for 802.1x

Hi everyone,

I’m looking for thoughts/opinions/experiences on 802.1x and security 
certificates. I dug through the archives from a few years ago, and from what I 
gather it isn’t even possible to use a 3rd-party cert so devices (iOS, OS X, 
Windows, Android) trust it automatically, but maybe someone has succeeded with 
this by now? If so, which CA would you recommend?

For us, our GoDaddy wildcard cert failed to authenticate clients, so we went 
with DigiCert. That isn’t trusted by clients by default, offering no benefit 
over our domain-generated cert, with which all Apple and Windows 8/10 devices 
must be told to “trust,” Windows 7 fails to authenticate entirely, and Android 
just works. We have a Cisco WLC and Windows NPS.

Thanks for any pointers you can give!

- Eric
This e-mail message is intended only for the person or entity to which it is 
addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender and destroy all copies of the 
original message. If you are the intended recipient but do not wish to receive 
communications through this medium, please so advise the sender immediately. 
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.