Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Craig Simons]

Rich,

Thank you for your detailed response. I should state that our certificate 
challenges were in fact due to the issuer chain changing (SHA-1 to SHA-2). 
Perhaps in the near-term, another certificate in the same chain would not be a 
repeat of last time. Still, with >60% of our mobile devices being Mac OSX/iOS 
based, I’m nervous that Apple will do something we don’t expect. In the end, 
any OnBoarding tool can only manipulate the APIs presented by the OS and each 
flavour of OS may have a different outcome.

I have taken your analysis to heart and it would appear that option 3 is 
probably the best way forward and we just need to ensure our support resources 
are set up to handle potential issues. Option 4 is a good long-term strategy, 
but for different reasons other than simply avoiding short term certificates.

Thanks,
 Craig

> On Oct 31, 2017, at 2:53 PM, Richard Nedwich  wrote:
> 
> Hi Craig,
> 
> I'm not sure if anyone from Cloudpath already advised you, but I did forward 
> your question to Kevin Koster, Cloudpath Founder and Chief Architect, for his 
> opinion of the pros/cons of these options.  I thought I would share them, in 
> case this forum found it useful.
> 
> Best,
> Rich
> -=-=-=-=-=-=-=
> 
> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
> "verify server certificate" enabled
> Pros:  You control the issuing CA, so you control if/when you change the 
> issuing CA.  Client will validate the RADIUS server certificate, thereby 
> protecting the user’s password and prevent device from connecting to 
> man-in-the-middle.  
> Cons:  Need to generate the private CA (ie need CA tool or openssl skills).  
> Need to install private CA on end-user devices (ie need onboarding tool).  
> 
> Option 2: Removing all traces of “verify server certificate” from OnBoard 
> configuration and use 2-year certs from CAs
> Pros:  “It just works.”
> Cons.  This disables all security built into WPA2-Enterprise.  Device will 
> give the password to any network, real or fake.  Device will join evil twins. 
>  
> Commentary:  With validation disabled, credentials are so at-risk that the 
> network’s attempt to authenticate wifi users becomes moot.  If you use this 
> model, you would do less damage to your end-users by using PSK (or even 
> better, Dynamic PSK) or having everyone use a static password (like 
> “password”).  
> 
> Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
> educate/prepare every two years for connection issues.
> Commentary:  This is essentially “use a public CA and be prepared to deal 
> with issues when issuer chain changes”.  This normally occurs when protocols 
> become obsolete (1024 to 2048, SHA-1 to SHA-2, etc), but can potentially 
> occur anytime.  For 802.1X, these changes are impactful to (properly 
> configured) end-users.  Unfortunately, most revenue for public CAs is from 
> web server certificates (which are not affected by issuing CA changes), so 
> they don’t always see chain changes as something to be avoided.  
> Pros:  Like #1, credentials are protected.
> Cons:  Requires client configuration.  If CA changes its chain, the network 
> will break for the device.  
> Work-Around:  The impact of this can be reduced by buying 2-year certificates 
> every 12 months.  Then, if the chain does change, you have a 12 month window 
> to transition.  This doesn’t change the need to transition, but it does 
> provide a window to make life easier.  
> 
> Option 4 (probably the best long-term answer): Move to private PKI and 
> EAP-TLS.
> Commentary:  While EAP-TLS has benefits beyond this particular issue, EAP-TLS 
> does not change this particular issue.  The following scenarios with EAP-TLS 
> would map to 1-3 above:  
> - Using EAP-TLS with a RADIUS cert from private CA would be similar to #1.  
> - Using EAP-TLS with a RADIUS cert from public CA would be similar to #3.  
> - Using EAP-TLS with server cert validation disabled would be similar to #2 
> (user would be still exposed to connecting to evil twins but the cleartext 
> password wouldn’t be leaked).
> 
> **
> 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] Radius certificate length vs. onboarding opinions

[Jethro R Binks]

> >> We are option 3 with 3 year certs.? We were in the same boat as Craig
> >> just over a year ago.? We moved to a different onboarding utility and
> >> different CA.? It is a long story so feel free to hit me up offline.?
> >> That said, in the future we will likely end up using both options 3 &
> >> 4 to be flexible with device/owner/use.
> >>
> >> ?
> >>
> >> ?
> >>
> >> ?
> >>
> >> */Mike Atkins?/*
> >> Network Engineer
> >> Office of Information Technology
> >> University of Notre Dame
> >> Phone: 574-631-7210
> >>
> >> ?
> >>
> >> ?
> >>
> >>  ? .__o
> >> ?? - _-\_<,
> >> ?? ---? (*)/'(*)
> >>
> >> ?
> >>
> >> *From:*?The EDUCAUSE Wireless Issues Constituent Group Listserv
> >> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> >> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]?*On Behalf Of?*Craig Simons
> >> *Sent:*?Monday, October 30, 2017 2:22 PM
> >> *To:*?WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> >> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> >> *Subject:*?[WIRELESS-LAN] Radius certificate length vs. onboarding
> >> opinions
> >>
> >> ?
> >>
> >> All,
> >>
> >> ?
> >>
> >> I know the subject has been broached on the list a few times before,
> >> but I’m looking for informal opinions/survey about how you are
> >> deploying your Radius EAP certificates for PEAP/TTLS users (non-TLS).
> >> We use Cloudpath to onboard users, but recently went through a
> >> difficult renewal period to replace our expiring certificate. As we
> >> had configured all of our clients to “verify the server certificate”
> >> (as you should from a security perspective), we found that iOS/MacOS
> >> and Android clients did not take kindly to a new certificate being
> >> presented. This resulted in quite a few disgruntled users who couldn’t
> >> connect to WiFi as well as a shell-shocked Service Desk. To help
> >> prevent this in the future (and because we are moving to a new Radius
> >> infrastructure), what is the consensus on the following strategies:
> >>
> >> ?
> >>
> >> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard
> >> with "verify server certificate" enabled
> >>
> >> ?
> >>
> >> Option 2: Removing all traces of “verify server certificate” from
> >> OnBoard configuration and use 2-year certs from CAs
> >>
> >> ?
> >>
> >> Option 3: Use 2-year CA certificates, enable “verify server
> >> certificates” and educate/prepare every two years for connection issues.
> >>
> >> ?
> >>
> >> Option 4 (probably the best long-term answer): Move to private PKI and
> >> EAP-TLS.
> >>
> >> ?
> >>
> >> Opinions?
> 
> -- 
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> 
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/discuss.
> 

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

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

Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[James Andrewartha]

The maximum for a public certificate is changing on 1 March 2018 to 27
months, with suggestions that it might drop down to 13 months later on:

https://www.digicert.com/shortening-validity-periods-for-ov-dv-certificates/
https://www.digicert.com/blog/cabforum-votes-shorten-certificate-lifetime-validity-periods-impacts/

One distinction about using a private CA is that you can have an
extremely long root CA, and then have shorter lived certificates signed
by that CA that are rotated. However, without onboarding to install the
CA for the SSID vs just trusting the certificate (which I know is what
macOS and iOS do) then it's not much of a distinction in practice. This
also means I have the same certificate installed on all RADIUS servers.

On EAP-TLS, we briefly tried enabling Windows Credential Guard last week
on a few IT laptops, and immediately had to turn it off as it breaks
MSCHAPv2 authentication:
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-considerations

I had a meeting with Microsoft yesterday and they said that certificate
auth is really the only secure answer. Since our devices are owned by
the school, we'll probably look at setting up a private Windows CA first
rather than going down the CloudPath or SecureW2 path.

On 31/10/17 12:46, Craig Simons wrote:
> These are very helpful and thoughtful points to consider. I think of
> this issue using the angel and devil on the shoulder analogy. On one
> shoulder, as a security conscious engineer (and technophile) I see why
> shorter certificates (I believe the maximum is 39 months now?) with all
> allowances made for security are the necessary evil. On the other, we
> want the campus WiFi experience to be easy, simple and as painless for
> the user (and Service Desk people) as possible. In many ways, a good
> onboarding tool lets you have your cake and eat it too... but our recent
> experience has shown us that even this has it’s limits.
> 
> I suppose the “correct” answer is the one that is supportable. This
> requires the Service Desk/Desktop Support people to be willing and able
> to handle the hordes when they arrive in the interests of security
> “tough love”.
> 
> However, I still believe there is a large role to play for EAP-TLS in
> the future. In the IoT world, the willingness of users to put their
> personal credentials on low-end devices is a security threat before even
> getting to the certificate conversation.
> 
> Thanks to all that replied!
> 
> *Craig Simons*
> Network Operations Manager
> 
> Simon Fraser University | Strand Hall
>  University Dr., Burnaby, B.C. V5A 1S6
> T: 778.782.8036 | M: 604.649.7977
> 
>       
> SFU   SIMON FRASER UNIVERSITY
> IT SERVICES
> 
> 
>> On Oct 30, 2017, at 1:19 PM, Mike Atkins <matk...@nd.edu
>> <mailto:matk...@nd.edu>> wrote:
>>
>> We are option 3 with 3 year certs.  We were in the same boat as Craig
>> just over a year ago.  We moved to a different onboarding utility and
>> different CA.  It is a long story so feel free to hit me up offline. 
>> That said, in the future we will likely end up using both options 3 &
>> 4 to be flexible with device/owner/use.
>>
>>  
>>
>>  
>>
>>  
>>
>> */Mike Atkins /*
>> Network Engineer
>> Office of Information Technology
>> University of Notre Dame
>> Phone: 574-631-7210
>>
>>  
>>
>>  
>>
>>    .__o
>>    - _-\_<,
>>    ---  (*)/'(*)
>>
>>  
>>
>> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Craig Simons
>> *Sent:* Monday, October 30, 2017 2:22 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Subject:* [WIRELESS-LAN] Radius certificate length vs. onboarding
>> opinions
>>
>>  
>>
>> All,
>>
>>  
>>
>> I know the subject has been broached on the list a few times before,
>> but I’m looking for informal opinions/survey about how you are
>> deploying your Radius EAP certificates for PEAP/TTLS users (non-TLS).
>> We use Cloudpath to onboard users, but recently went through a
>> difficult renewal period to replace our expiring certificate. As we
>> had configured all of our clients to “verify the server certificate”
>> (as you should from a security perspective), we found that iOS/MacOS
>> and Android clients did not take kindly to a new certificate being
>> presented. This resulted in quite a few disgruntled users who couldn’t
>> connect to WiFi as well as a she

Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Walter Reynolds]

We use SecureW2 JoinNow and the actually recommend option 2.  Still the
security vs. simplicity for users.

We are using option 3 and the last change in certificate we had overall
went pretty well.  We did try hard to get some media out there to notify
users as well as worked with the help desk and unit IT support.  Yes there
were still issues but it was not as bad as I was fearing.

Though to be honest I think most people either just accepted the pop up to
trust the new cert if they got it or removed their settings and started
from scratch (again getting a pop up).  The majority of the users are
students and they have pretty much grown up with Wi-Fi and are not afraid
of it.



Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Tue, Oct 31, 2017 at 12:46 AM, Craig Simons <craigsim...@sfu.ca> wrote:

> These are very helpful and thoughtful points to consider. I think of this
> issue using the angel and devil on the shoulder analogy. On one shoulder,
> as a security conscious engineer (and technophile) I see why shorter
> certificates (I believe the maximum is 39 months now?) with all allowances
> made for security are the necessary evil. On the other, we want the campus
> WiFi experience to be easy, simple and as painless for the user (and
> Service Desk people) as possible. In many ways, a good onboarding tool lets
> you have your cake and eat it too... but our recent experience has shown us
> that even this has it’s limits.
>
> I suppose the “correct” answer is the one that is supportable. This
> requires the Service Desk/Desktop Support people to be willing and able to
> handle the hordes when they arrive in the interests of security “tough
> love”.
>
> However, I still believe there is a large role to play for EAP-TLS in the
> future. In the IoT world, the willingness of users to put their personal
> credentials on low-end devices is a security threat before even getting to
> the certificate conversation.
>
> Thanks to all that replied!
>
> *Craig Simons*
> Network Operations Manager
>
> Simon Fraser University | Strand Hall
>  University Dr., Burnaby, B.C. V5A 1S6
> <https://maps.google.com/?q=+University+Dr.,+Burnaby,+B.C.+V5A+1S6=gmail=g>
> T: 778.782.8036 <(778)%20782-8036> | M: 604.649.7977 <(604)%20649-7977>
>
>
> SFU SIMON FRASER UNIVERSITY
> IT SERVICES
>
> On Oct 30, 2017, at 1:19 PM, Mike Atkins <matk...@nd.edu> wrote:
>
> We are option 3 with 3 year certs.  We were in the same boat as Craig just
> over a year ago.  We moved to a different onboarding utility and different
> CA.  It is a long story so feel free to hit me up offline.  That said, in
> the future we will likely end up using both options 3 & 4 to be flexible
> with device/owner/use.
>
>
>
>
>
>
> *Mike Atkins *
> Network Engineer
> Office of Information Technology
> University of Notre Dame
> Phone: 574-631-7210 <(574)%20631-7210>
>
>
>
>
>    .__o
>- _-\_<,
>---  (*)/'(*)
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Craig Simons
> *Sent:* Monday, October 30, 2017 2:22 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] Radius certificate length vs. onboarding
> opinions
>
>
> All,
>
>
> I know the subject has been broached on the list a few times before, but
> I’m looking for informal opinions/survey about how you are deploying your
> Radius EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to
> onboard users, but recently went through a difficult renewal period to
> replace our expiring certificate. As we had configured all of our clients
> to “verify the server certificate” (as you should from a security
> perspective), we found that iOS/MacOS and Android clients did not take
> kindly to a new certificate being presented. This resulted in quite a few
> disgruntled users who couldn’t connect to WiFi as well as a shell-shocked
> Service Desk. To help prevent this in the future (and because we are moving
> to a new Radius infrastructure), what is the consensus on the following
> strategies:
>
>
> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with
> "verify server certificate" enabled
>
>
> Option 2: Removing all traces of “verify server certificate” from OnBoard
> configuration and use 2-year certs from CAs
>
>
> Option 3: Use 2-year CA certificates, enable “verify server certificates”
> and educate/prepare every two years for connection issues.
>
>
> Option 4 (probably the best long-term a

Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Craig Simons]

These are very helpful and thoughtful points to consider. I think of this issue 
using the angel and devil on the shoulder analogy. On one shoulder, as a 
security conscious engineer (and technophile) I see why shorter certificates (I 
believe the maximum is 39 months now?) with all allowances made for security 
are the necessary evil. On the other, we want the campus WiFi experience to be 
easy, simple and as painless for the user (and Service Desk people) as 
possible. In many ways, a good onboarding tool lets you have your cake and eat 
it too... but our recent experience has shown us that even this has it’s limits.

I suppose the “correct” answer is the one that is supportable. This requires 
the Service Desk/Desktop Support people to be willing and able to handle the 
hordes when they arrive in the interests of security “tough love”.

However, I still believe there is a large role to play for EAP-TLS in the 
future. In the IoT world, the willingness of users to put their personal 
credentials on low-end devices is a security threat before even getting to the 
certificate conversation.

Thanks to all that replied!

Craig Simons
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977

 
SFU SIMON FRASER UNIVERSITY
IT SERVICES

> On Oct 30, 2017, at 1:19 PM, Mike Atkins <matk...@nd.edu> wrote:
> 
> We are option 3 with 3 year certs.  We were in the same boat as Craig just 
> over a year ago.  We moved to a different onboarding utility and different 
> CA.  It is a long story so feel free to hit me up offline.  That said, in the 
> future we will likely end up using both options 3 & 4 to be flexible with 
> device/owner/use.
>  
>  
>  
> Mike Atkins 
> Network Engineer
> Office of Information Technology
> University of Notre Dame
> Phone: 574-631-7210
>  
>  
>    .__o
>- _-\_<,
>---  (*)/'(*)
>  
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Craig Simons
> Sent: Monday, October 30, 2017 2:22 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions
>  
> All,
>  
> I know the subject has been broached on the list a few times before, but I’m 
> looking for informal opinions/survey about how you are deploying your Radius 
> EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
> users, but recently went through a difficult renewal period to replace our 
> expiring certificate. As we had configured all of our clients to “verify the 
> server certificate” (as you should from a security perspective), we found 
> that iOS/MacOS and Android clients did not take kindly to a new certificate 
> being presented. This resulted in quite a few disgruntled users who couldn’t 
> connect to WiFi as well as a shell-shocked Service Desk. To help prevent this 
> in the future (and because we are moving to a new Radius infrastructure), 
> what is the consensus on the following strategies:
>  
> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
> "verify server certificate" enabled
>  
> Option 2: Removing all traces of “verify server certificate” from OnBoard 
> configuration and use 2-year certs from CAs
>  
> Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
> educate/prepare every two years for connection issues.
>  
> Option 4 (probably the best long-term answer): Move to private PKI and 
> EAP-TLS.
>  
> Opinions?
>  
> Craig Simons
> Network Operations Manager
> 
> Simon Fraser University | Strand Hall
>  University Dr., Burnaby, B.C. V5A 1S6
> T: 778.782.8036 | M: 604.649.7977 | www.sfu.ca/itservices 
> <http://www.sfu.ca/itservices>
> 
> 
>  
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/discuss <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 <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] Radius certificate length vs. onboarding opinions

[Turner, Ryan H]

We went option 4 several years ago.  I actually learned the lesson about root 
certificate server changes about 4 years ago.  It is one of the things I have 
mentioned when I gave a presentation in the past about 'Lessons learned with 
Certificate Based Authentications'.


EAP-TLS will require PROPER user onboarding, which means you can install the 
private CA chain.  In my opinion, private is the way to go.  YOU control your 
CA destiny, not some external provider.


Ryan Turner


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Craig Simons 
<craigsim...@sfu.ca>
Sent: Monday, October 30, 2017 2:21:57 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

All,

I know the subject has been broached on the list a few times before, but I’m 
looking for informal opinions/survey about how you are deploying your Radius 
EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
users, but recently went through a difficult renewal period to replace our 
expiring certificate. As we had configured all of our clients to “verify the 
server certificate” (as you should from a security perspective), we found that 
iOS/MacOS and Android clients did not take kindly to a new certificate being 
presented. This resulted in quite a few disgruntled users who couldn’t connect 
to WiFi as well as a shell-shocked Service Desk. To help prevent this in the 
future (and because we are moving to a new Radius infrastructure), what is the 
consensus on the following strategies:

Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
"verify server certificate" enabled

Option 2: Removing all traces of “verify server certificate” from OnBoard 
configuration and use 2-year certs from CAs

Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
educate/prepare every two years for connection issues.

Option 4 (probably the best long-term answer): Move to private PKI and EAP-TLS.

Opinions?

Craig Simons
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | 
www.sfu.ca/itservices<http://www.sfu.ca/itservices>

[http://www.sfu.ca/content/dam/sfu/creative-studio/images/email/sfu-horizontal.png]

** 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] Radius certificate length vs. onboarding opinions

[Oakes, Carl W]

We just went option 1, did a self-signed 20 year CA, then generated radius 
certs off that.   Only role/function of that CA is for RADIUS.  (PEAP-MSCHAPv2).
For the most part, things went well, we use SecureW2 for onboarding if clients 
choose to do so, which installs the CA and sets the verification check, with a 
wildcard against the domain so any number of radius server changes could be in 
play.. (*.network.).

Only issues so far with this:

1 - Windows 7 will not trust the cert unless you onboard / install the CA, just 
joining the network doesn't work.
2 - We've had about a dozen Windows 10 clients fail to connect out of 1,000's.  
Appears to be a software/patching issue, chasing with Microsoft now.   If we 
boot the problem machine from a clean windows 10 boot disk, works fine.

I doubt we will get 20 years out of it.  Sometime before hand we will probably 
need to update due to encryption levels, exploits, new methods, etc.  But at 
least we won't be changing simply because the timer ran out. :)

I look forward to option 4 in the near future, although it doesn't fully solve 
the issue, but since folks need to onboard, makes things easier to manage.

Carl Oakes
California State University Sacramento



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Enfield
Sent: Monday, October 30, 2017 2:24 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

Thanks Philippe.  Hadn’t thought about fragmentation coming from the internet.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Philippe Hanset
Sent: Monday, October 30, 2017 5:08 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

All,

We love option 4 but it has its issues...and on that note let me share (with 
his permission) a tidbit from Curtis Larsen from University of Utah
sent to the eduroam-admins list about EAP-TLS and firewalls/load balancer.
Make a mental note for the future ;-), it took us a while to discover that 
problem: Fragmentation, fragmentation, fragmentation.

Best,

Philippe

Philippe Hanset
www.anyroam.net<http://www.anyroam.net>

--
From Curtis:

We resolved this today working with our Firewall team but I wanted to thank 
Chad with Anyroam support for helping with the pcaps and suggesting a look at 
fragmentation initially.

It turns out our problem had to do with how fragmented packets are handled by 
our border firewalls and our chosen load-balancing method on the respective 
port-channel interfaces.  The key is that we needed to balance these RADIUS 
sessions/transactions on source/dest. IP alone instead of including the TCP/UDP 
port as well.  The problem did not occur with PEAP MSCHAPv2 tests because the 
packets never fragmented and thus all had the same UDP port number and all got 
marked as the same session/transaction and sent out the same interface.  
Sometimes we got lucky and all EAP-TLS packets needed for a single 
authentication went the same way and it worked but often packets went different 
ways and the fragments were not able to be marked as part of the same 
session/transaction and that is when my server got half of the packets.

Curtis K. Larsen
Senior Wi-Fi Network Engineer
University of Utah IT/CIS
Office 801-587-1313
--

On Oct 30, 2017, at 4:19 PM, Mike Atkins 
<matk...@nd.edu<mailto:matk...@nd.edu>> wrote:

We are option 3 with 3 year certs.  We were in the same boat as Craig just over 
a year ago.  We moved to a different onboarding utility and different CA.  It 
is a long story so feel free to hit me up offline.  That said, in the future we 
will likely end up using both options 3 & 4 to be flexible with 
device/owner/use.



Mike Atkins
Network Engineer
Office of Information Technology
University of Notre Dame
Phone: 574-631-7210


   .__o
   - _-\_<,
   ---  (*)/'(*)

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of Craig Simons
Sent: Monday, October 30, 2017 2:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

All,

I know the subject has been broached on the list a few times before, but I’m 
looking for informal opinions/survey about how you are deploying your Radius 
EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
users, but recently went through a difficult renewal period to replace our 
expiring certificate. As we had configured all of our clients to “verify the 
server certificate” (as you should from a security perspective), we found that 
iOS/MacOS and Android clients did not t

RE: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Chuck Enfield]

Thanks Philippe.  Hadn’t thought about fragmentation coming from the 
internet.



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Philippe Hanset
Sent: Monday, October 30, 2017 5:08 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Radius certificate length vs. onboarding 
opinions



All,



We love option 4 but it has its issues...and on that note let me share (with 
his permission) a tidbit from Curtis Larsen from University of Utah

sent to the eduroam-admins list about EAP-TLS and firewalls/load balancer.

Make a mental note for the future ;-), it took us a while to discover that 
problem: Fragmentation, fragmentation, fragmentation.



Best,



Philippe

Philippe Hanset

www.anyroam.net <http://www.anyroam.net>


--

>From Curtis:



We resolved this today working with our Firewall team but I wanted to thank 
Chad with Anyroam support for helping with the pcaps and suggesting a look 
at fragmentation initially.



It turns out our problem had to do with how fragmented packets are handled 
by our border firewalls and our chosen load-balancing method on the 
respective port-channel interfaces.  The key is that we needed to balance 
these RADIUS sessions/transactions on source/dest. IP alone instead of 
including the TCP/UDP port as well.  The problem did not occur with PEAP 
MSCHAPv2 tests because the packets never fragmented and thus all had the 
same UDP port number and all got marked as the same session/transaction and 
sent out the same interface.  Sometimes we got lucky and all EAP-TLS packets 
needed for a single authentication went the same way and it worked but often 
packets went different ways and the fragments were not able to be marked as 
part of the same session/transaction and that is when my server got half of 
the packets.

Curtis K. Larsen
Senior Wi-Fi Network Engineer
University of Utah IT/CIS
Office 801-587-1313

--



On Oct 30, 2017, at 4:19 PM, Mike Atkins <matk...@nd.edu 
<mailto:matk...@nd.edu> > wrote:



We are option 3 with 3 year certs.  We were in the same boat as Craig just 
over a year ago.  We moved to a different onboarding utility and different 
CA.  It is a long story so feel free to hit me up offline.  That said, in 
the future we will likely end up using both options 3 & 4 to be flexible 
with device/owner/use.







Mike Atkins

Network Engineer

Office of Information Technology

University of Notre Dame

Phone: 574-631-7210





   .__o

   - _-\_<,

   ---  (*)/'(*)



From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: 
<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Simons
Sent: Monday, October 30, 2017 2:22 PM
To:  <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions



All,



I know the subject has been broached on the list a few times before, but I’m 
looking for informal opinions/survey about how you are deploying your Radius 
EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
users, but recently went through a difficult renewal period to replace our 
expiring certificate. As we had configured all of our clients to “verify the 
server certificate” (as you should from a security perspective), we found 
that iOS/MacOS and Android clients did not take kindly to a new certificate 
being presented. This resulted in quite a few disgruntled users who couldn’t 
connect to WiFi as well as a shell-shocked Service Desk. To help prevent 
this in the future (and because we are moving to a new Radius 
infrastructure), what is the consensus on the following strategies:



Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
"verify server certificate" enabled



Option 2: Removing all traces of “verify server certificate” from OnBoard 
configuration and use 2-year certs from CAs



Option 3: Use 2-year CA certificates, enable “verify server certificates” 
and educate/prepare every two years for connection issues.



Option 4 (probably the best long-term answer): Move to private PKI and 
EAP-TLS.



Opinions?



Craig Simons
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 |  <http://www.sfu.ca/itservices> 
www.sfu.ca/itservices






** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
<http://www.educause.edu/discuss> 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> http://www.educause.edu/discuss.



** Participation and subscription 

Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Philippe Hanset]

All,

We love option 4 but it has its issues...and on that note let me share (with 
his permission) a tidbit from Curtis Larsen from University of Utah
sent to the eduroam-admins list about EAP-TLS and firewalls/load balancer. 
Make a mental note for the future ;-), it took us a while to discover that 
problem: Fragmentation, fragmentation, fragmentation.

Best,

Philippe

Philippe Hanset
www.anyroam.net <http://www.anyroam.net/>

--
From Curtis:

We resolved this today working with our Firewall team but I wanted to thank 
Chad with Anyroam support for helping with the pcaps and suggesting a look at 
fragmentation initially.

It turns out our problem had to do with how fragmented packets are handled by 
our border firewalls and our chosen load-balancing method on the respective 
port-channel interfaces.  The key is that we needed to balance these RADIUS 
sessions/transactions on source/dest. IP alone instead of including the TCP/UDP 
port as well.  The problem did not occur with PEAP MSCHAPv2 tests because the 
packets never fragmented and thus all had the same UDP port number and all got 
marked as the same session/transaction and sent out the same interface.  
Sometimes we got lucky and all EAP-TLS packets needed for a single 
authentication went the same way and it worked but often packets went different 
ways and the fragments were not able to be marked as part of the same 
session/transaction and that is when my server got half of the packets.

Curtis K. Larsen
Senior Wi-Fi Network Engineer
University of Utah IT/CIS
Office 801-587-1313
--

> On Oct 30, 2017, at 4:19 PM, Mike Atkins <matk...@nd.edu> wrote:
> 
> We are option 3 with 3 year certs.  We were in the same boat as Craig just 
> over a year ago.  We moved to a different onboarding utility and different 
> CA.  It is a long story so feel free to hit me up offline.  That said, in the 
> future we will likely end up using both options 3 & 4 to be flexible with 
> device/owner/use.
>  
>  
>  
> Mike Atkins 
> Network Engineer
> Office of Information Technology
> University of Notre Dame
> Phone: 574-631-7210
>  
>  
>    .__o
>- _-\_<,
>---  (*)/'(*)
>  
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Craig Simons
> Sent: Monday, October 30, 2017 2:22 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions
>  
> All,
>  
> I know the subject has been broached on the list a few times before, but I’m 
> looking for informal opinions/survey about how you are deploying your Radius 
> EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
> users, but recently went through a difficult renewal period to replace our 
> expiring certificate. As we had configured all of our clients to “verify the 
> server certificate” (as you should from a security perspective), we found 
> that iOS/MacOS and Android clients did not take kindly to a new certificate 
> being presented. This resulted in quite a few disgruntled users who couldn’t 
> connect to WiFi as well as a shell-shocked Service Desk. To help prevent this 
> in the future (and because we are moving to a new Radius infrastructure), 
> what is the consensus on the following strategies:
>  
> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
> "verify server certificate" enabled
>  
> Option 2: Removing all traces of “verify server certificate” from OnBoard 
> configuration and use 2-year certs from CAs
>  
> Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
> educate/prepare every two years for connection issues.
>  
> Option 4 (probably the best long-term answer): Move to private PKI and 
> EAP-TLS.
>  
> Opinions?
>  
> Craig Simons
> Network Operations Manager
> 
> Simon Fraser University | Strand Hall
>  University Dr., Burnaby, B.C. V5A 1S6
> T: 778.782.8036 | M: 604.649.7977 | www.sfu.ca/itservices 
> <http://www.sfu.ca/itservices>
> 
> 
>  
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/discuss <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 <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] Radius certificate length vs. onboarding opinions

[Oliver, Jeff]

We are currently in the option 3 track. Because the vast majority of the 
devices are not corporate we have not really considered the self-signed options 
at all. We are trying to educate our user base not to click through cert 
warnings, and the once every couple years we do change out the cert comes with 
a couple prior notices stating that it will happen on such-and-such a date.

Cheers,
Jeff

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Simons
Sent: Monday, October 30, 2017 12:22 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

All,

I know the subject has been broached on the list a few times before, but I’m 
looking for informal opinions/survey about how you are deploying your Radius 
EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
users, but recently went through a difficult renewal period to replace our 
expiring certificate. As we had configured all of our clients to “verify the 
server certificate” (as you should from a security perspective), we found that 
iOS/MacOS and Android clients did not take kindly to a new certificate being 
presented. This resulted in quite a few disgruntled users who couldn’t connect 
to WiFi as well as a shell-shocked Service Desk. To help prevent this in the 
future (and because we are moving to a new Radius infrastructure), what is the 
consensus on the following strategies:

Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
"verify server certificate" enabled

Option 2: Removing all traces of “verify server certificate” from OnBoard 
configuration and use 2-year certs from CAs

Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
educate/prepare every two years for connection issues.

Option 4 (probably the best long-term answer): Move to private PKI and EAP-TLS.

Opinions?

Craig Simons
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | 
www.sfu.ca/itservices<http://www.sfu.ca/itservices>

[http://www.sfu.ca/content/dam/sfu/creative-studio/images/email/sfu-horizontal.png]

** 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] Radius certificate length vs. onboarding opinions

[Mike Atkins]

We are option 3 with 3 year certs.  We were in the same boat as Craig just
over a year ago.  We moved to a different onboarding utility and different
CA.  It is a long story so feel free to hit me up offline.  That said, in
the future we will likely end up using both options 3 & 4 to be flexible
with device/owner/use.







*Mike Atkins *

Network Engineer

Office of Information Technology

University of Notre Dame

Phone: 574-631-7210





   .__o

   - _-\_<,

   ---  (*)/'(*)



*From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Craig Simons
*Sent:* Monday, October 30, 2017 2:22 PM
*To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
*Subject:* [WIRELESS-LAN] Radius certificate length vs. onboarding opinions



All,



I know the subject has been broached on the list a few times before, but
I’m looking for informal opinions/survey about how you are deploying your
Radius EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to
onboard users, but recently went through a difficult renewal period to
replace our expiring certificate. As we had configured all of our clients
to “verify the server certificate” (as you should from a security
perspective), we found that iOS/MacOS and Android clients did not take
kindly to a new certificate being presented. This resulted in quite a few
disgruntled users who couldn’t connect to WiFi as well as a shell-shocked
Service Desk. To help prevent this in the future (and because we are moving
to a new Radius infrastructure), what is the consensus on the following
strategies:



Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with
"verify server certificate" enabled



Option 2: Removing all traces of “verify server certificate” from OnBoard
configuration and use 2-year certs from CAs



Option 3: Use 2-year CA certificates, enable “verify server certificates”
and educate/prepare every two years for connection issues.



Option 4 (probably the best long-term answer): Move to private PKI and
EAP-TLS.



Opinions?



*Craig Simons*
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | www.sfu.ca/itservices




** 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] Radius certificate length vs. onboarding opinions

[Doug Wussler]

We tried to move to Option 1 this year but management was not comfortable with 
the use of a Private CA.  Like you, we used the term “self-signed” and that 
does not come off well.  Technically, it is not a “self-signed” certificate, it 
is signed by your Private CA (which, of course, is self-signed like every 
public root).

So, we remain on Option 3.


Doug Wussler
Application Developer/Designer – Core Network Team
Information Technology Services
RK Shaw Building
644 W. Call Street
Tallahassee, FL  32304


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Michael Davis <da...@udel.edu>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Monday, October 30, 2017 at 2:45 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

We're on Option 3, first time this Semester so we haven't gone through an 
update yet.
(We use the eduroam CAT application)

Android before v7.1 have a known issue not being able to have 2 certificates at 
once.
Any iOS will have a warning that it hasn't seen that certificate before, but it 
shouldn't
be an error.
What MacOS issues were you seeing?

We're exploring Option 4, and it'll be a race to see if we get there before the 
Cert renews...



On 10/30/17 2:21 PM, Craig Simons wrote:
All,

I know the subject has been broached on the list a few times before, but I’m 
looking for informal opinions/survey about how you are deploying your Radius 
EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to onboard 
users, but recently went through a difficult renewal period to replace our 
expiring certificate. As we had configured all of our clients to “verify the 
server certificate” (as you should from a security perspective), we found that 
iOS/MacOS and Android clients did not take kindly to a new certificate being 
presented. This resulted in quite a few disgruntled users who couldn’t connect 
to WiFi as well as a shell-shocked Service Desk. To help prevent this in the 
future (and because we are moving to a new Radius infrastructure), what is the 
consensus on the following strategies:

Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
"verify server certificate" enabled

Option 2: Removing all traces of “verify server certificate” from OnBoard 
configuration and use 2-year certs from CAs

Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
educate/prepare every two years for connection issues.

Option 4 (probably the best long-term answer): Move to private PKI and EAP-TLS.

Opinions?

Craig Simons
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | 
www.sfu.ca/itservices<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sfu.ca_itservices=DwMDaQ=HPMtquzZjKY31rtkyGRFnQ=iWHlmRoKGsiAUGML4kxiTFSMVFjSJWPJZ-Qyls6lSv0=U35BXXsr4r2sH1mcPJL0epuzwO7Oq1mwipWtZJhBa_Q=cyGweN9WgaGdwt1BRtevadYWYeAoRyzfkZa9UVTGvEo=>

[http://www.sfu.ca/content/dam/sfu/creative-studio/images/email/sfu-horizontal.png]

** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss=DwMDaQ=HPMtquzZjKY31rtkyGRFnQ=iWHlmRoKGsiAUGML4kxiTFSMVFjSJWPJZ-Qyls6lSv0=U35BXXsr4r2sH1mcPJL0epuzwO7Oq1mwipWtZJhBa_Q=IOetDuRMS2xCOeZDG5osySzrzpboqh13UQV-l04t_xo=>.




--

 Mike Davis

 Systems Programmer V

 NSS - University of Delaware  - 302.831.8756

 Newark, DE  19716 Email da...@udel.edu<mailto:da...@udel.edu>
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss=DwMDaQ=HPMtquzZjKY31rtkyGRFnQ=iWHlmRoKGsiAUGML4kxiTFSMVFjSJWPJZ-Qyls6lSv0=U35BXXsr4r2sH1mcPJL0epuzwO7Oq1mwipWtZJhBa_Q=IOetDuRMS2xCOeZDG5osySzrzpboqh13UQV-l04t_xo=>.

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

Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Michael Davis]

We're on Option 3, first time this Semester so we haven't gone through 
an update yet.

(We use the eduroam CAT application)

Android before v7.1 have a known issue not being able to have 2 
certificates at once.
Any iOS will have a warning that it hasn't seen that certificate before, 
but it shouldn't

be an error.
What MacOS issues were you seeing?

We're exploring Option 4, and it'll be a race to see if we get there 
before the Cert renews...




On 10/30/17 2:21 PM, Craig Simons wrote:

All,

I know the subject has been broached on the list a few times before, 
but I’m looking for informal opinions/survey about how you are 
deploying your Radius EAP certificates for PEAP/TTLS users (non-TLS). 
We use Cloudpath to onboard users, but recently went through a 
difficult renewal period to replace our expiring certificate. As we 
had configured all of our clients to “verify the server certificate” 
(as you should from a security perspective), we found that iOS/MacOS 
and Android clients did not take kindly to a new certificate being 
presented. This resulted in quite a few disgruntled users who couldn’t 
connect to WiFi as well as a shell-shocked Service Desk. To help 
prevent this in the future (and because we are moving to a new Radius 
infrastructure), what is the consensus on the following strategies:


Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard 
with "verify server certificate" enabled


Option 2: Removing all traces of “verify server certificate” from 
OnBoard configuration and use 2-year certs from CAs


Option 3: Use 2-year CA certificates, enable “verify server 
certificates” and educate/prepare every two years for connection issues.


Option 4 (probably the best long-term answer): Move to private PKI and 
EAP-TLS.


Opinions?

*Craig Simons*
Network Operations Manager

Simon Fraser University | Strand Hall
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | www.sfu.ca/itservices 




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





--
 Mike Davis
 Systems Programmer V
 NSS - University of Delaware  - 302.831.8756
 Newark, DE  19716 Email da...@udel.edu


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