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 almost all third parties, that have public docs, 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. ... View more