Filter
Top Products
8-71
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Chapter 8 Managing Users and Identity Stores
Configuring CA Certificates
Click Submit to save the RADIUS Identity Server.
Related Topics
• RADIUS Identity Stores, page 8-63
• Creating, Duplicating, and Editing RADIUS Identity Servers, page 8-66
Configuring CA Certificates
When a client uses the EAP-TLS protocol to authenticate itself against the ACS server, it sends a client
certificate that identifies itself to the server. To verify the identity and correctness of the client certificate,
the server must have a preinstalled certificate from the Certificate Authority (CA) that has digitally
signed the client certificate.
If ACS does not trust the client’s CA certificate, then you must install in ACS the entire chain of
successively signed CA certificates, all the way to the top-level CA certificate that ACS trusts. CA
certificates are also known as trust certificates.
You use the CA options to install digital certificates to support EAP-TLS authentication. ACS uses the
X.509 v3 digital certificate standard. ACS also supports manual certificate acquisition and provides the
means for managing a certificate trust list (CTL) and certificate revocation lists (CRLs).
Digital certificates do not require the sharing of secrets or stored database credentials. They can be
scaled and trusted over large deployments. If managed properly, they can serve as a method of
authentication that is stronger and more secure than shared secret systems.
Mutual trust requires that ACS have an installed certificate that can be verified by end-user clients. This
server certificate may be issued from a CA or, if you choose, may be a self-signed certificate. For more
information, see Configuring Local Server Certificates, page 18-14.
Table 8-21 RADIUS Identity Server - Advanced Tab
Option Description
This Identity Store does not differentiate between 'authentication failed' and 'user not found' when an authentication attempt
is rejected. From the options below, select how such an authentication reject from the Identity Store should be interpreted by
ACS for Identity Policy processing and reporting.
Treat Rejects as 'authentication failed' Click this option to consider all ambiguous access reject attempts as failed
authentications.
Treat Rejects as 'user not found' Click this option to consider all ambiguous access reject attempts as
unknown users.
Identity caching is used to allow processing of requests that do not perform authentication against the server. The cache
retains the results and attributes retrieved from the last successful authentication for the subject.
Enable identity caching Check this check box to enable identity caching. If you enable identity
caching, you must enter the time in minutes for which you want ACS to
retain the identity cache.
Aging Time n Minutes Enter the time in minutes for which you want ACS to retain the identity
cache. Valid options are from 1 to 1440.