07-11-2025 03:03 AM
I'm currently evaluating Meraki Access Manager for EAP-TLS certificate-based authentication, and I'm a bit unclear on the CA requirements.
Some earlier articles I've come across suggest that third-party or external CAs may not be required, implying that Meraki might handle certificate issuance internally. However, in the Access Manager interface, I only see an option to upload CA certificates, which seems to indicate we’d need to bring our own PKI.
Can someone clarify:
Do we need to use our own Certificate Authority (e.g., Microsoft CA, SecureW2, etc.) for EAP-TLS authentication with Access Manager, or is there a built-in Meraki CA that can issue and manage certificates for clients?
Thanks in advance.
07-11-2025 03:24 AM
No, Meraki Access Manager does not currently include a built-in Certificate Authority (CA) to issue client certificates.
Meraki does provide its own RADIUS server certificate (used by Access Manager and local RADIUS on MR) that you can download and install on client devices to ensure trust during the TLS handshake.
Access Manager - EAP-TLS Client Configuration (Windows, macOS and iOS) - Cisco Meraki Documentation
However, when you use Meraki MDM, you can use Meraki certificates.
07-11-2025 06:34 AM
07-11-2025 02:29 PM
I am using a root certificate from one of our Windows domain controllers and I am getting this error. Any thoughts?
The provided certificate is untrusted. This might be due to its signer being disabled, extra or duplicate certificates in the chain, or another untrusted reason.
Verify that the certificate chain does not contain duplicate or unnecessary certificates. Additionally, refer to the certificates page to ensure the signer is enabled and the chain is valid.
08-12-2025 01:08 PM
I am working through this myself as there is no documentation on how to do this with a Windows CA. But what I have come up with so far is.
I have gotten it to work with an endpoint certificate, and I am now working on the user part with Entra.
07-13-2025 06:21 PM
Meraki Access Manager does not include a CA.
However, Meraki Systems Manager does - and Meraki Access Manager can use those certificates.
https://documentation.meraki.com/SM/Profiles_and_Settings/Certificates_in_Meraki_Systems_Manager
I've also set it up using Microsoft Intune CloudPKI.
You could use a Microsoft CA server in an AD environment and configure group policy to deploy certificates to machines/users.
08-20-2025 04:24 PM
Take a look at this access manager + cloud pki guide
09-11-2025 07:54 AM
Make sure upload and *Enable* your CA, then have your client configured to use a cert issues by your CA, create a access rule to match the CA [like common name]
01-29-2026 02:05 PM
I got a quote for Access Manager, and the pricing is ridiculous. The fact that I have to pay the amount of money they quoted me so I can securely do NAC on their hardware is ridiculous.
01-30-2026 05:10 AM
The prices are a bit lower than ISE session licenses. And I do believe an ISE like environment is running the radius services.
They could of course do a little extra effort and provide full blown profiling and perhaps an optional native cloud PKI so you don't need to rely on MS Cloud PKI or SCEPman.
05-06-2026 07:05 AM
I am trying the same thing but using MOSYLE/SCEP to deploy a wifi certificate profile into iMac/Macbooks and got the same error message described by another comment. The link to Hypershift gives me some clues but I would have to take a packet capture from Meraki Dashboard AP to see what it is going on with the failed connection.
We will also try Airwatch MDM for iPads, hoping that ones works. The wifi profile that we deployed with BOTH MDM's work fine with Cisco ISE EAP-TLS, but not with Access Manager.
We cannot configure 50K+ devices using the "manual" instructions from Meraki documentation.
05-06-2026 01:43 PM
I have a vague recollection of issues when using SCEP to deploy certificates to Apple devices from a Microsoft CA server.
Sorry, this is vague, it was a while ago. I'm hoping this might get you "searching" in the correct direction.
But we ran into an issue where the root CA certificate itself was not using strong enough encryption. We have to upgrade the key size, hash, and cryptographic algorithms on the CA root certificate itself. Some part of the equation (and I don't remember exactly what at the moment) refused the connection because it failed this check.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide