> When the supplicant is properly configured, it is not dependent on an
> individual leaf certificate and will not be impacted by the renewal of
> the EAP server certificate.
I thought we were talking about the client certs. Rereading the thread, I
was probably the only one thinking that.
Answering the PKI questions and expanding on Tim's response:
1. The authentication server should present the whole chain, leaf to
root. The client should trust the root, and expect a specific CN in
the leaf. This is what lets you renew the leaf server certs without
reconfiguring clients. [1]
2. The free eduroamCAT tool does this. Any on-boarding agent that is
worth using will, too.
3a. As your private PKI is not part of the Browser/CA forum or any other
regulatory body, you are not required to have an HSM for your root
key. [2]
3b. There is no use for an HSM if you are using the InCommon root. In
this scenario, only sensitive information that you have control over
is the key to the leaf cert.
[1] Note that this how the client authenticates the server, and therefore
is not specific to EAP/TLS.
[2] This does not necessarily mean you do not _want_ one. That is a
security decision that your group will have to make. All security involves
trade-offs, and trade-offs are subjective.
--
Jonathan Waldrep
Network Engineer
Network Infrastructure and Services
Virginia Tech
On Wed, Feb 12, 2020 at 3:14 PM Cappalli, Tim (Aruba) <[email protected]> wrote:
>
> When the supplicant is properly configured, it is not dependent on an
> individual leaf certificate and will not be impacted by the renewal of the
> EAP server certificate.
>
>
>
> tim
>
>
>
> From: The EDUCAUSE Wireless Issues Community Group Listserv
> <[email protected]>
> Date: Friday, February 7, 2020 at 1:42 PM
> To: [email protected] <[email protected]>
> Subject: Re: [WIRELESS-LAN] EAP-TLS using ADCS and/or SecureW2
>
> > Would you recommend we use an incommon public signed cert even if we’re
> > able to have every BYOD client install our self-signed cert?
> No. The InCommon CA must adhere to the CA/Browser forum's rules for a
> CA. As such, the lifetime of the cert is limited to just over 2 years.
> Having a network connection break after 2 years, for no apparent
> reason, is a frustrating user experience. Using your own PKI/CA does
> not have this restriction.
>
> --
> Jonathan Waldrep
> Network Engineer
> Network Infrastructure and Services
> Virginia Tech
>
> On Thu, Feb 6, 2020 at 9:26 PM Turner, Ryan H <[email protected]> wrote:
> >
> > I would suggest using SecureW2s PKI and not AD. We ran SecureW2 integrated
> > with the ADCS for about 5 or 6 years. It works, but it adds some
> > additional complexity that will cause you grief. For example, let’s say
> > one night the integration server that ties to SecureW2 patches and hangs
> > after a reboot…. Or the process that handles the certificate request (a
> > SecureW2 process on your AD server) dies… The users trying to onboard will
> > get ambiguous errors, and you will spend a lot of time trying to figure out
> > if the problem is 1) the user, 2) the cloud, 3) your AD integration server,
> > 4) the certificate server. It really helps to have everything in one
> > basket.
> >
> >
> >
> > We switched to the SecureW2 cloud based PKI in January. I am going to
> > answer your other questions inline below…
> >
> >
> >
> > From: "[email protected]"
> > <[email protected]> on behalf of "Heavrin, Lynn"
> > <[email protected]>
> > Reply-To: "[email protected]"
> > <[email protected]>
> > Date: Thursday, February 6, 2020 at 3:23 PM
> > To: "[email protected]"
> > <[email protected]>
> > Subject: [WIRELESS-LAN] EAP-TLS using ADCS and/or SecureW2
> >
> >
> >
> > We’re planning to migrate our PEAP MSCHAPv2 wifi to EAP-TLS. At the
> > recommendation of a couple big universities we talked with, we are looking
> > at using SecureW2. We have demoed it and it works great provisioning the
> > clients and enrolling user certificates to their cloud PKI. After bringing
> > it up with our AD team, some questions were asked about possibly just using
> > our ADCS. We know we can use the ADCS with or without SecureW2 and will
> > likely leverage SecureW2 anyway to point to it for nice features like OS
> > detection and provisioning and a good dissolvable agent. We use Cisco ISE
> > for our RADIUS server and I much prefer SecureW2’s agent over ISE.
> >
> >
> >
> > I was asked a couple questions and I may or may not already know the
> > answer, but it’d be great if someone with a little more PKI background
> > could clarify:
> >
> >
> >
> > Private PKI questions:
> >
> > Does every Managed and BYOD device have to trust the full chain of the
> > certificate?
> >
> > I don’t think you can make any assumptions. As I recall, we install every
> > certificate and chain it all the way back to root.
> >
> > How do you install the trusted root and intermediate on a BYOD device?
> >
> > That is what SecureW2 does during the onboarding.
> >
> > For a private PKI with a self-signed cert do we need an HSM? If we use
> > incommon root, would we need the HSM?
> >
> > I think this is extreme overkill. If you are going to create a new PKI, it
> > should only be trusted on the RADIUS servers for campus internet
> > connectivity. The certificate shouldn’t give access to any other campus
> > resource, so its value it extremely limited.
> >
> >
> >
> >
> >
> > SecureW2 Questions:
> >
> > Does the SecureW2 JoinNow MultiOS dissolvable agent install the root and
> > intermediate on a BYOD device during enrollment? If so then it shouldn’t
> > matter if we use a self-signed root or incommon public root right?
> > We are also an incommon partner and can get root signed certs from them.
> > If we used incommon root but pointed securew2 to our ADCS, would that be an
> > unnecessary step rather than just pointing SecureW2 straight to incommon
> > like we’re doing in our demo?
> > Would you recommend we use an incommon public signed cert even if we’re
> > able to have every BYOD client install our self-signed cert? We have
> > unlimited incommon certs. We may already have been issuing user certs to
> > all our managed devices, just not doing anything with them. One thing I
> > thought was that any BYOD could be incommon, and all managed would be
> > self-signed and I could just set ISE to trust both.
> >
> >
> >
> > I’ll make this simple. While your situation may differ from ours, I do not
> > think there will be a compelling reason for you to use InCommon. A Private
> > PKI is simple. SecureW2 will easily install the chains. You will not have
> > to worry about InCommon. I’m just going to leave it at that. While I
> > don’t have the precise number, I am fairly confident we’ve devices nearly
> > 1M times on SecureW2 (and previously Cloudpath). When it comes to TLS,
> > your absolute best bet is to not complicate. 2048 length certs and SHA256
> > hash. Simple. Works. No benefit to complicating.
> >
> >
> >
> > My 10 cents.
> >
> >
> >
> > Ryan
> >
> >
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Lynn Heavrin
> >
> > Network Engineer II | Network Engineering
> >
> > Washington University in St. Louis
> >
> > 4480 Clayton Ave, St. Louis, MO 63110
> >
> > Mail stop 8218-45-1200
> > (: 314.935.3877 | *:[email protected]
> >
> >
> >
> > ________________________________
> >
> > The materials in this message are private and may contain Protected
> > Healthcare Information or other information of a sensitive nature. If you
> > are not the intended recipient, be advised that any unauthorized use,
> > disclosure, copying or the taking of any action in reliance on the contents
> > of this information is strictly prohibited. If you have received this email
> > in error, please immediately notify the sender via telephone or return mail.
> >
> > **********
> > Replies to EDUCAUSE Community Group emails are sent to the entire community
> > list. If you want to reply only to the person who sent the message, copy
> > and paste their email address and forward the email reply. Additional
> > participation and subscription information can be found at
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.educause.edu_community&d=DwIFaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=8-eiWdtQQnWdOzvxaW4-nQ&m=66igePoMZUFH8ExosE0UZH--_9dibJkv1aFMOv_PAPY&s=qUxiCwlce7b9wHVZ7OWCjpS3DpQymtcBYoyJ76WtJcU&e=
> >
> > **********
> > Replies to EDUCAUSE Community Group emails are sent to the entire community
> > list. If you want to reply only to the person who sent the message, copy
> > and paste their email address and forward the email reply. Additional
> > participation and subscription information can be found at
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.educause.edu_community&d=DwIFaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=8-eiWdtQQnWdOzvxaW4-nQ&m=66igePoMZUFH8ExosE0UZH--_9dibJkv1aFMOv_PAPY&s=qUxiCwlce7b9wHVZ7OWCjpS3DpQymtcBYoyJ76WtJcU&e=
>
> **********
> Replies to EDUCAUSE Community Group emails are sent to the entire community
> list. If you want to reply only to the person who sent the message, copy and
> paste their email address and forward the email reply. Additional
> participation and subscription information can be found at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.educause.edu_community&d=DwIFaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=8-eiWdtQQnWdOzvxaW4-nQ&m=66igePoMZUFH8ExosE0UZH--_9dibJkv1aFMOv_PAPY&s=qUxiCwlce7b9wHVZ7OWCjpS3DpQymtcBYoyJ76WtJcU&e=
>
> **********
> Replies to EDUCAUSE Community Group emails are sent to the entire community
> list. If you want to reply only to the person who sent the message, copy and
> paste their email address and forward the email reply. Additional
> participation and subscription information can be found at
> https://www.educause.edu/community
**********
Replies to EDUCAUSE Community Group emails are sent to the entire community
list. If you want to reply only to the person who sent the message, copy and
paste their email address and forward the email reply. Additional participation
and subscription information can be found at https://www.educause.edu/community
