Hotspot 2.0 RadSec Setup - Workaround for Third-Party Provided AAA

neuro
Comes here often

Hotspot 2.0 RadSec Setup - Workaround for Third-Party Provided AAA

I'm attempting to set up Hotspot 2.0 using RadSec on Meraki. The client I am working with provides the AAA server (Radiator) and has provided the CA certs, client cert, and client key. Radsec authentication is a requirement. The issue I am faced with is that they are opposed to importing each individual Meraki Org's CA root certificate to their radius server.

 

I am wondering what possible workarounds are available to accomplish this task. Radsecproxy is an option, but is less than ideal for this scenario.

 

Yes, I've opened a case with TAC some time ago and I got the standard answer from the docs. I understand that this is typically not how RadSec is set up. However, I've been able to accomplish this with other vendors. I'm intimately familiar with Meraki wireless (two years installing Meraki solutions for recognized brands at an MSP). I also have a decent understanding of PKIs/Cert based auth, but am by no means an expert. Perhaps I am overlooking something relatively obvious here.

 

 

With all that, I'd like to express my appreciation to those of you who took the time to read this post. Thank you!

 

https://documentation.meraki.com/MR/Encryption_and_Authentication/MR_RADSec

2 Replies 2
alemabrahao
Kind of a big deal

If your client is opposed to importing each individual Meraki Org's CA root certificate, you could explore the possibility of using an intermediate CA. This way, you can have a single intermediate CA that is trusted by both the Meraki Org and the AAA server. This might simplify the certificate management process.

 

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
WayFI-Simeon
New here

On most platforms that support RadSec, the standard approach is to install the CA that signed the upstream RadSec server along with the client certificate and key.

Requiring an additional CA—whether intermediate or not—introduces unnecessary complexity and deviates from industry-standard configurations. The expectation is that the upstream server should trust certificates issued by its designated CA, without requiring per-organization root certificates to be imported.

If the objective is to avoid deploying a proxy server, then Meraki’s current implementation creates significant barriers to interoperability and practical deployment. It's effectively useless in 3p RADSEC server configurations. This approach renders RadSec authentication cumbersome and, in many cases, impractical without additional workarounds.


It's bad enough that third parties such as IronWiFi, Google Orion, and WeFi all default to using a proxy of some kind to work around these limitations. The unnecessary complexity of Meraki's RadSec implementation likely results in many RADIUS packets being transmitted unencrypted over the wire—something that should be a baseline security concern. As a result, even products from Ubiquiti end up offering better default security than Meraki in this regard.

I would be interested to hear if anyone has found an alternative solution that aligns more closely with standard RadSec deployments, without requiring a proxy server.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco ID. If you don't yet have a Cisco ID, you can sign up.
Labels