Is there a way to provide all the necessary intermediate certificates to an ACS v5.3 so that it can provide the full chain to the client during a 802.1x PEAP authentication?
Already tried to install the EAP certificate with the chain and also installed the issuing CA as trusted root. I know that installing it as trusted root shouldn't have any effect but that's the way how Cisco solved it on the ASA platforms.
If you get a certificate e.g. from Verisign it will be issued from a subordinate and not from the root itself. So if you want to do PEAP-MS-CHAP with an unmanaged client who has only the root certificates installed and is configured to verify the server certificate during the PEAP TLS tunnel establishment you will need to provide the whole cert chain to the client, so it can establish the trust link up to the root. So there must be a way of providing the whole chain. Otherwise the ACS is useless for authentication with unmanaged clients who verify the server certificate.
Unfortunately, any radius server (not just the ACS) will be not be able to supply the certificate (intermediate or root) for installation to the client during the PEAP tunnel process as that is not as per RFC.
There is some additional feature to facilitate this on Cisco ISE, but only an ISE expert can comment on that.
Could you elaborate, on unmanaged client?
What type of client would this be, is this a BYOD environment?
It's not about INSTALLING a certificate. It's about providing the whole chain during authentication so that the client can establish itself the link to the responsible root. As any well managed webserver should do who runs on HTTPS.
Here the wireshark example of a TLS tunnel to https://supportforums.cisco.com/
And we need the ACS to behave the same during the establishment of the TLS tunnel during a PEAP authentication.
Unfortunately I don't have a capture, as I don't have access to the network infrastructure between the ACS and the WLC. And Wireshark doesn't capture the PEAP authentication on my wireless NIC during the connection phase.
If you can give it a try it would be great. But from my current tests the ACS doesn't seem to do that, as the clients without the intermediates refuse to talk to the "RADIUS server", as they can't verify it's identity against a trusted root. With the intermediate cert locally installed they work well and trust the "RADIUS Server".
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...