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. Errrr > > 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 looooooong 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 every $certexpiry interval? Someone could interlope a rogue radius server presenting a certificate with the correct name if they can get in the user-ap-radius data path, but it won't be signed with the root you've installed so it will be rejected. Your protection is entirely based in the matching of the servername as configured in the client with the certificate presented by the radius server, which ties to a known root cert. That is regardless of the source of the certs, and is why you are very strongly recommended (and the CAT tool enforces) configuring the radius server name in the client. From what I recall, if you don't, any cert will be accepted from a radius server as long as it is signed by a known root. If I understood the risk correctly, that means someone could get a cert via a well known CA, use it on a radius server, MITM that into the path, and your client will probably trust it because it has that CA root/intermediates (experts can clarify if I've got that right). Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . 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. *** Please note I will be uncontactable 31st Mar to 18th Apr 2017 *** ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
