About Digital Certificates
Digital certificates provide digital identification for authentication. A digital certificate includes information that identifies a device or user, such as the name, serial number, company, department, or IP address. CAs are responsible for managing certificate requests and issuing digital certificates. CAs are trusted authorities that “sign” certificates to verify their authenticity, thereby guaranteeing the identity of the device or user.
A digital certificate also includes a copy of the public key for the user or device. A CA can be a trusted third party, such as VeriSign, or a private (in-house) CA that you establish within your organization. CAs issue digital certificates in the context of a PKI, which uses public-key or private-key encryption to ensure security.
For authentication using digital certificates, at least one identity certificate and its issuing CA certificate must exist on an ASA. This configuration allows multiple identities, roots, and certificate hierarchies. The ASA evaluates third-party certificates against CRLs, also called authority revocation lists, all the way from the identity certificate up the chain of subordinate certificate authorities.
Descriptions of several different types of available digital certificates follow:
-
A CA certificate is used to sign other certificates. It is self-signed and called a root certificate. A certificate that is issued by another CA certificate is called a subordinate certificate.
-
CAs also issue identity certificates, which are certificates for specific systems or hosts.
-
Code-signer certificates are special certificates that are used to create digital signatures to sign code, with the signed code itself revealing the certificate origin.
The local CA integrates an independent certificate authority feature on the ASA, deploys certificates, and provides secure revocation checking of issued certificates. The local CA provides a secure, configurable, in-house authority for certificate authentication with user enrollment through a website login page.
Note |
CA certificates and identity certificates apply to both site-to-site VPN connections and remote access VPN connections. Procedures in this document refer to remote access VPN use in the ASDM GUI. |
Tip |
For an example of a scenario that includes certificate configuration and load balancing, see the following URL: https://supportforums.cisco.com/docs/DOC-5964. |
Public Key Cryptography
Digital signatures, enabled by public key cryptography, provide a way to authenticate devices and users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other.
In simple terms, a signature is formed when data is encrypted with a private key. The signature is attached to the data and sent to the receiver. The receiver applies the public key of the sender to the data. If the signature sent with the data matches the result of applying the public key to the data, the validity of the message is established.
This process relies on the receiver having a copy of the public key of the sender and a high degree of certainty that this key belongs to the sender, not to someone pretending to be the sender.
Obtaining the public key of a sender is normally handled externally or through an operation performed at installation. For example, most web browsers are configured with the root certificates of several CAs by default. For VPN, the IKE protocol, a component of IPsec, can use digital signatures to authenticate peer devices before setting up security associations.
Certificate Scalability
Without digital certificates, you must manually configure each IPsec peer for each peer with which it communicates; as a result, each new peer that you add to a network would require a configuration change on each peer with which it needs to communicate securely.
When you use digital certificates, each peer is enrolled with a CA. When two peers try to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new peer is added to the network, you enroll that peer with a CA and none of the other peers need modification. When the new peer attempts an IPsec connection, certificates are automatically exchanged and the peer can be authenticated.
With a CA, a peer authenticates itself to the remote peer by sending a certificate to the remote peer and performing some public key cryptography. Each peer sends its unique certificate, which was issued by the CA. This process works because each certificate encapsulates the public key for the associated peer, each certificate is authenticated by the CA, and all participating peers recognize the CA as an authenticating authority. The process is called IKE with an RSA signature.
The peer can continue sending its certificate for multiple IPsec sessions, and to multiple IPsec peers, until the certificate expires. When its certificate expires, the peer administrator must obtain a new one from the CA.
CAs can also revoke certificates for peers that no longer participate in IPsec. Revoked certificates are not recognized as valid by other peers. Revoked certificates are listed in a CRL, which each peer may check before accepting a certificate from another peer.
Some CAs have an RA as part of their implementation. An RA is a server that acts as a proxy for the CA, so that CA functions can continue when the CA is unavailable.
Key Pairs
Key pairs are RSA or Elliptic Curve Signature Algorithm (ECDSA) keys, which have the following characteristics:
-
RSA keys can be used for SSH or SSL.
-
SCEP enrollment supports the certification of RSA keys.
-
The maximum RSA key size is 4096, and the default is 2048.
-
The maximum ECDSA key length is 521, and the default is 384.
-
You can generate a general purpose RSA key pair, used for both signing and encryption, or you can generate separate RSA key pairs for each purpose. Separate signing and encryption keys help to reduce exposure of the keys, because SSL uses a key for encryption but not signing. However, IKE uses a key for signing but not encryption. By using separate keys for each, exposure of the keys is minimized.
Trustpoints
Trustpoints let you manage and track CAs and certificates. A trustpoint is a representation of a CA or identity pair. A trustpoint includes the identity of the CA, CA-specific configuration parameters, and an association with one, enrolled identity certificate.
After you have defined a trustpoint, you can reference it by name in commands requiring that you specify a CA. You can configure many trustpoints.
Note |
If the ASA has multiple trustpoints that share the same CA, only one of these trustpoints sharing the CA can be used to validate user certificates. To control which trustpoint sharing a CA is used for validation of user certificates issued by that CA, use the support-user-cert-validation command. |
For automatic enrollment, a trustpoint must be configured with an enrollment URL, and the CA that the trustpoint represents must be available on the network and must support SCEP.
You can export and import the keypair and issued certificates associated with a trustpoint in PKCS12 format. This format is useful to manually duplicate a trustpoint configuration on a different ASA.
Certificate Enrollment
The ASA needs a CA certificate for each trustpoint and one or two certificates for itself, depending upon the configuration of the keys used by the trustpoint. If the trustpoint uses separate RSA keys for signing and encryption, the ASA needs two certificates, one for each purpose. In other key configurations, only one certificate is needed.
The ASA supports automatic enrollment with SCEP and with manual enrollment, which lets you paste a base-64-encoded certificate directly into the terminal. For site-to-site VPNs, you must enroll each ASA. For remote access VPNs, you must enroll each ASA and each remote access VPN client.
Proxy for SCEP Requests
The ASA can proxy SCEP requests between AnyConnect Client and a third-party CA. The CA only needs to be accessible to the ASA if it is acting as the proxy. For the ASA to provide this service, the user must authenticate using any of the methods supported by AAA before the ASA sends an enrollment request. You can also use host scan and dynamic access policies to enforce rules of eligibility to enroll.
The ASA supports this feature only with an AnyConnect Client SSL or IKEv2 VPN session. It supports all SCEP-compliant CAs, including Cisco IOS CS, Windows Server 2003 CA, and Windows Server 2008 CA.
Clientless (browser-based) access does not support SCEP proxy, although WebLaunch—clientless-initiated AnyConnect Client—does support it.
The ASA does not support polling for certificates.
The ASA supports load balancing for this feature.
Revocation Checking
When a certificate is issued, it is valid for a fixed period of time. Sometimes a CA revokes a certificate before this time period expires; for example, because of security concerns or a change of name or association. CAs periodically issue a signed list of revoked certificates. Enabling revocation checking forces the ASA to check that the CA has not revoked a certificate each time that it uses the certificate for authentication.
When you enable revocation checking, the ASA checks certificate revocation status during the PKI certificate validation process, which can use either CRL checking, OCSP, or both. OCSP is only used when the first method returns an error (for example, indicating that the server is unavailable).
With CRL checking, the ASA retrieves, parses, and caches CRLs, which provide a complete list of revoked (and unrevoked) certificates with their certificate serial numbers. The ASA evaluates certificates according to CRLs, also called authority revocation lists, from the identity certificate up the chain of subordinate certificate authorities.
OCSP offers a more scalable method of checking revocation status in that it localizes certificate status through a validation authority, which it queries for status of a specific certificate.
Supported CA Servers
The ASA supports the following CA servers:
Cisco IOS CS, ASA Local CA, and third-party X.509 compliant CA vendors including, but not limited to:
-
Baltimore Technologies
-
Entrust
-
Digicert
-
Geotrust
-
GoDaddy
-
iPlanet/Netscape
-
Microsoft Certificate Services
-
RSA Keon
-
Thawte
-
VeriSign
CRLs
CRLs provide the ASA with one way of determining whether a certificate that is within its valid time range has been revoked by the issuing CA. CRL configuration is part of configuration of a trustpoint.
You can configure the ASA to make CRL checks mandatory when authenticating a certificate by using the revocation-check crl command. You can also make the CRL check optional by using the revocation-check crl none command, which allows the certificate authentication to succeed when the CA is unavailable to provide updated CRL data.
Note |
The revocation-check crl none was removed. |
The ASA can retrieve CRLs from CAs using HTTP, SCEP, or LDAP. CRLs retrieved for each trustpoint are cached for a configurable amount of time for each trustpoint.
Note |
Though the CRL server responds with HTTP flag "Connection: Keep-alive" to indicate a persistent connection, ASA does not request support for persistent connection. Change the settings on the CRL server to respond with "Connection: Close" when the list is sent. |
When the ASA has cached a CRL for longer than the amount of time it is configured to cache CRLs, the ASA considers the CRL too old to be reliable, or “stale.” The ASA tries to retrieve a newer version of the CRL the next time that a certificate authentication requires a check of the stale CRL.
You could receive a revocation check failure for a user connection/certificate if you exceed the CRL size limit of 16 MB.
The ASA caches CRLs for an amount of time determined by the following two factors:
-
The number of minutes specified with the cache-time command. The default value is 60 minutes.
-
The NextUpdate field in the CRLs retrieved, which may be absent from CRLs. You control whether the ASA requires and uses the NextUpdate field with the enforcenextupdate command.
The ASA uses these two factors in the following ways:
-
If the NextUpdate field is not required, the ASA marks CRLs as stale after the length of time defined by the cache-time command.
-
If the NextUpdate field is required, the ASA marks CRLs as stale at the sooner of the two times specified by the cache-time command and the NextUpdate field. For example, if the cache-time command is set to 100 minutes and the NextUpdate field specifies that the next update is 70 minutes away, the ASA marks CRLs as stale in 70 minutes.
If the ASA has insufficient memory to store all CRLs cached for a given trustpoint, it deletes the least recently used CRL to make room for a newly retrieved CRL. Large CRLs require significant computational overhead to parse them. Hence, for better performance, use many CRLs of smaller size rather than few large CRLs, or preferably, use OCSP.
See the following the cache sizes:
-
Single context mode—128 MB
-
Multiple context mode—16 MB per context
OCSP
OCSP provides the ASA with a way of determining whether a certificate that is within its valid time range has been revoked by the issuing CA. OCSP configuration is part of trustpoint configuration.
OCSP localizes certificate status on a validation authority (an OCSP server, also called the responder) which the ASA queries for the status of a specific certificate. This method provides better scalability and more up-to-date revocation status than does CRL checking, and helps organizations with large PKI installations deploy and expand secure networks.
Note |
The ASA allows a five-second time skew for OCSP responses. |
You can configure the ASA to make OCSP checks mandatory when authenticating a certificate by using the revocation-check ocsp command. You can also make the OCSP check optional by using the revocation-check ocsp none command, which allows the certificate authentication to succeed when the validation authority is unavailable to provide updated OCSP data.
Note |
The revocation-check ocsp none was removed. |
OCSP provides three ways to define the OCSP server URL. The ASA uses these servers in the following order:
-
The OCSP URL defined in a match certificate override rule by using the match certificate command).
-
The OCSP URL configured by using the ocsp url command.
-
The AIA field of the client certificate.
Note |
To configure a trustpoint to validate a self-signed OCSP responder certificate, you import the self-signed responder certificate into its own trustpoint as a trusted CA certificate. Then you configure the match certificate command in the client certificate validating trustpoint to use the trustpoint that includes the self-signed OCSP responder certificate to validate the responder certificate. Use the same procedure for configuring validating responder certificates external to the validation path of the client certificate. The OCSP server (responder) certificate usually signs the OCSP response. After receiving the response, the ASA tries to verify the responder certificate. The CA normally sets the lifetime of the OCSP responder certificate to a relatively short period to minimize the chance of being compromised. The CA usually also includes an ocsp-no-check extension in the responder certificate, which indicates that this certificate does not need revocation status checking. However, if this extension is not present, the ASA tries to check revocation status using the same method specified in the trustpoint. If the responder certificate is not verifiable, revocation checks fail. To avoid this possibility, use the revocation-check none command to configure the responder certificate validating trustpoint, and use the revocation-check ocsp command to configure the client certificate. |
Certificates and User Login Credentials
The following section describes the different methods of using certificates and user login credentials (username and password) for authentication and authorization. These methods apply to IPsec, AnyConnect Client, and Clientless SSL VPN.
In all cases, LDAP authorization does not use the password as a credential. RADIUS authorization uses either a common password for all users or the username as a password.
User Login Credentials
The default method for authentication and authorization uses the user login credentials.
-
Authentication
-
Enabled by the authentication server group setting in the tunnel group (also called ASDM Connection Profile)
-
Uses the username and password as credentials
-
-
Authorization
-
Enabled by the authorization server group setting in the tunnel group (also called ASDM Connection Profile)
-
Uses the username as a credential
-
Certificates
If user digital certificates are configured, the ASA first validates the certificate. It does not, however, use any of the DNs from certificates as a username for the authentication.
If both authentication and authorization are enabled, the ASA uses the user login credentials for both user authentication and authorization.
-
Authentication
-
Enabled by the authentication server group setting
-
Uses the username and password as credentials
-
-
Authorization
-
Enabled by the authorization server group setting
-
Uses the username as a credential
-
If authentication is disabled and authorization is enabled, the ASA uses the primary DN field for authorization.
-
Authentication
-
DISABLED (set to None) by the authentication server group setting
-
No credentials used
-
-
Authorization
-
Enabled by the authorization server group setting
-
Uses the username value of the certificate primary DN field as a credential
-
Note |
If the primary DN field is not present in the certificate, the ASA uses the secondary DN field value as the username for the authorization request. |
For example, consider a user certificate that includes the following Subject DN fields and values:
Cn=anyuser,OU=sales;O=XYZCorporation;L=boston;S=mass;C=us;ea=anyuser@example.com
If the Primary DN = EA (E-mail Address) and the Secondary DN = CN (Common Name), then the username used in the authorization request would be anyuser@example.com.