> 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 <rhtur...@email.unc.edu> 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: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "Heavrin, Lynn" > <lheav...@wustl.edu> > Reply-To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Date: Thursday, February 6, 2020 at 3:23 PM > To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > 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 | *:lheav...@wustl.edu > > > > ________________________________ > > 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://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 ********** 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
