Cisco Cisco Identity Services Engine Software Manual Técnica

Even when “Validate Server Identity” is disabled on the supplicant, the SSL handshake may
fail when the “*” is in the CN field. 

●

Instead, a generic FQDN can be used in the CN field, and then the “*.domain.com” can be used on the Subject Alternative Name (SAN) DNS Name

field.

●

Note:  Some Certificate Authorities (CA) may add the wildcard (*) in the CN of the certificate automatically even if it not present in the CSR. In this scenario, a
special request will need to me made to prevent this action.

Note: Each deployment node(s)’s IP address can be added to the SAN field to avoid a certificate warning when you access the server via the IP address..

Once the CSR has been created, ISE will display a pop up window with the option to export it. Once exported, this file should be sent to the CA for signing.

The Certificate Authority will return the signed server certificate along with the full signing chain (Root/Intermediate). Once received, follow the steps below to
import the certificates into your ISE server.

Import any Root and (or) Intermediate certificates provided by the CA by going to Administration > Certificates > Trusted Certificates.

1.

Import the Server certificate by going to Administration >> Certificates >> Certificate Signing Requests.

2.

Select the CSR previously created and click on Bind Certificate.

3.

Select the new certificate location and ISE will bind the certificate to the private key created and stored in the database.

4.

Note: If the Admin Role has been selected for this certificate, ISE will restart services.

If the admin role was selected during the certificate import you can verify the new certificate is in place by loading the admin page in the browser.  The
browser should trust the new admin certificate as long as the chain was built correctly and if the certificate chain is trusted by the browser.

For additional verification select the lock symbol in the browser and under the certificate path verify the full chain is present and trusted by the machine.  This
is not a direct indicator that the full chain was passed down correctly by the server but an indicator of the browser able to trust the server certificate based on
its local trust store.

Verify ISE is passing the full certificate chain during the SSL handshake process.

When using EAP methods that require a server certificate (i.e. PEAP) and “Validate Server Identity” is selected, the supplicant will validate the certificate
chain using the certificates it has in its local trust store as part of the authentication process. As part of the SSL handshake process ISE will present its
certificate and  also any Root and (or) intermediate certificates present in its chain.  The supplicant won’t be able to validate the server identity if the chain is
incomplete. To verify the certificate chain is passed back to your client, you can perform the following steps:

Take a capture from ISE (TCPDump) during the authentication. Found under Operations > Diagostic Tools > General Tools > TCP Dump

1.

Download/Open the capture and apply the filter “ssl.handshake.certificates”  in Wireshark and find an access-challenge.

2.

Once Selected, Expand Radius Protocol > Attribute Value Pairs > EAP-Message Last segment > Extensible Authentication Protocol >  Secure

Sockets Layer >  Certificate  > Certificates

3.

 Certificate chain in the capture.

If the chain is not complete you should go to ISE Administration > Certificates > Trusted Certificates and verify that the Root and (or) Intermediate certificates