topic Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate in Network Access Control

12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

a.burlaos — Fri, 21 Feb 2020 18:32:06 GMT

Hi,

I'm quite new to the system and i'm currently installing Cisco ISE 2.1. I've tried to connect 1 windows client (added to the domain) to ISE using the default policy. My authentication order from the switch is dot1x then Mab then WebAuth but when the client tried to authenticate using dot1x ISE receive an error (12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate). Then the windows client will successfully authenticate as MAB instead of dot1x.

Any suggestion or any missing configurations needed to authenticate windows client using wired 802.1x?

Also, what is the correct entry for cts sxp commands?

Switch configuration:

logging monitor informational

aaa new-model

aaa authentication enable default enable

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa authorization auth-proxy default group CiscoISE

aaa accounting auth-proxy default start-stop group CiscoISE

aaa accounting dot1x default start-stop group radius

aaa session-id common

ip dhcp snooping vlan 51

no ip dhcp snooping information option

ip dhcp snooping

no ip domain-lookup

ip domain-name xu.local

ip device tracking

ip admission name CiscoISE proxy http

cts sxp enable

cts sxp default source-ip 172.16.1.170

cts sxp default password 7 09747B441A54044259071C23

cts sxp connection peer 10.200.1.165 password default mode peer listener

dot1x system-auth-control

fallback profile CiscoISE

ip access-group CiscoISE in

ip admission CiscoISE

interface GigabitEthernet1/0/1

switchport access vlan 51

switchport mode access

switchport block unicast

switchport voice vlan 10

ip arp inspection limit rate 60

ip access-group ACL-DEFAULT in

authentication event fail action next-method

authentication host-mode multi-auth

authentication open

authentication order dot1x mab webauth

authentication priority dot1x mab

authentication port-control auto

authentication timer inactivity 60

authentication violation restrict

authentication fallback Dot1X

mab

snmp trap mac-notification change added

dot1x pae authenticator

dot1x timeout tx-period 60

spanning-tree portfast

spanning-tree bpduguard enable

ip dhcp snooping limit rate 60

logging origin-id ip

logging source-interface Vlan999

logging host 10.200.1.165 transport udp port 20514

snmp-server community cisosnmp RO

snmp-server community public RW

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart

snmp-server host 10.200.1.165 mac mac-notification snmp

snmp-server host 10.200.1.165 public

radius-server attribute 6 on-for-login-auth

radius-server attribute 6 support-multiple

radius-server attribute 8 include-in-access-req

radius-server host 10.200.1.165 auth-port 1812 acct-port 1813 key 7 112A484114425A3F57

radius-server vsa send accounting

radius-server vsa send authentication

Regards,

Arvie

Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

vrostowsky — Wed, 26 Apr 2017 16:07:49 GMT

Nino-

The client machine is not accepting the certificate from Cisco ISE since it cannot validate it. It isn't a best practice to use ISE as the certificate authority. If you have a server that is capable to run CA services, that would be a better scenario. You must have the certificate chain from the CA server (root CA) installed on the client as well as in ISE trusted certificates in order to have PKI function correctly.

HTH-

Vince

Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

a.burlaos — Tue, 09 May 2017 02:55:03 GMT

Hi Vince,

Thank you for the response. Do you have any recommendations or best approach if I have this kind of setup?

Scenario:

1. AD Server

2. CA Server (not the AD server)

3. Cisco ISE Server

4. Domain PC

5. Non Domain PC

Regards,

Arvie

Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

Arne Bier — Tue, 09 May 2017 03:21:10 GMT

Have a look at the very good and extensive blog from Katherine

ISE - Adding Certificates to ISE and Creating Certificate Profiles

For EAP-PEAP you could also try to configure your client to ignore server certificate checking and then it won't validate the ISE server certificate. But that is just a quick and dirty workaround.

I have also written a blog article on using OpenSSL as a Certificate Authority in case you cannot get your hands on a Windows CA - you can of course also use ISE as your CA.

Rapid prototyping ISE Policies without any real networking hardware (part 3)

The answer is always 'it depends...'. But in my experience, when doing EAP-TLS you're best off using an enterprise CA such as Windows Server because it integrates well with AD, and also provides certificate revocation services (CRL/OCSP). It is also well understood in most IT Enterprises. For lab purposes you can get away with openssl.

Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

a.burlaos — Tue, 09 May 2017 03:54:57 GMT

Hi Arne,

Thank you.

Actually I already checked and followed Katherine's Post. I already downloaded the CA Cert from CA server to ISE as trusted certificate but from the client side what I did to make the authentication successful is I manually added the default self-signed from the system certificate of ISE to windows 7 and windows 8 clients. Is it the same certificate should I used in order for the AD to push to windows clients?

Regards,

Arvie

Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

Arne Bier — Tue, 09 May 2017 04:35:48 GMT

Installing the ISE self-signed certificate in clients will certainly work - but the self signed certs will expire pretty soon (I think out of the box they are valid for 1 year only). Self signed certs are mostly useful for getting you started - but you should rather consider creating an externally signed certificate for your ISE servers. You can create longer lasting certificates on external CA.

One of the immediate benefits of using your corporate CA's, is that if your clients already have your corporate CA chain in their trust store, then they will automatically trust ISE because it was signed by that CA hierarchy. No need to push the ISE self signed cert to all Windows clients.

i.e. your organisation 'MegaCorp' could have a PKI hierarchy as follows

Mega-Root-CA

Mega-Issuing-CA

You push this CA chain to all of your corporate workstations as Trusted Certificates.

On ISE you will create a certificate signing request on your PAN for 'EAP Authentication' for the PSN's that you require (use the SAN feature so that you can make one certificate for all of your PAN's - if you like). Hand the CSR to your PKI and get back the certificate which you then bind to the PSN(s).

When your windows clients perform an EAP-PEAP auth they will then honour the ISE server cert (as long as it's still valid and not revoked) because the ISE cert was signed by the Mega-Issuing-CA, which is a windows trusted CA.

Re: 12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate

Jason Kunst — Wed, 25 Jul 2018 22:12:16 GMT

Is your windows supplicant trusting the ISE certificate? Under the windows supplicant configuration you either have to explicitly trust ISE certificate (best with well known certificate installed on your ISE or you have to manually install ISE self signed certificate on the client itself) or remove the requirement for trust