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: 1. 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. 1. How do you install the trusted root and intermediate on a BYOD device? That is what SecureW2 does during the onboarding. 1. 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: 1. 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? 2. 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? 3. 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<mailto: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
