Table Of Contents
Configuring Authorization and Revocation of Certificates in a PKI
Prerequisites for Authorization and Revocation of Certificates
Restrictions for Authorization and Revocation of Certificates
Information About Authorization and Revocation of Certificates
PKI and AAA Server Integration for Certificate Status
RADIUS or TACACS+: Choosing a AAA Server Protocol
Attribute-Value Pairs for PKI and AAA Server Integration
CRLs or OCSP Server: Choosing a Certificate Revocation Mechanism
When to Use Certificate-Based ACLs for Authorization or Revocation
Ignore Revocation Checks Using a Certificate-Based ACL
PKI Certificate Chain Validation
How to Configure Authorization and Revocation of Certificates for Your PKI
Configuring PKI Integration with a AAA Server
Restrictions When Using the Entire Subject Name for PKI Authorization
Configuring a Revocation Mechanism for PKI Certificate Status Checking
Nonces and Peer Communications with OCSP Servers
Configuring Certificate Authorization and Revocation Settings
Configuring Certificate-Based ACLs to Ignore Revocation Checks
Manually Overriding CDPs in a Certificate
Manually Overriding the OCSP Server Setting in a Certificate
Configuring Certificate Serial Number Session Control
Configuring Certificate Chain Validation
Configuring Certificate Servers for High Availability
Configuring SCTP on the Active and Standby Certificate Servers
Setting Redundancy Mode on Certificate Servers to ACTIVE/STANDBY
Synchronizing the Active and Standby Certificate Servers
Configuration Examples for Setting Up Authorization and Revocation of Certificates
Configuring and Verifying PKI AAA Authorization: Examples
Debug of a Successful PKI AAA Authorization: Example
Debugs of a Failed PKI AAA Authorization: Example
Configuring a Revocation Mechanism: Examples
Configuring an OCSP Server: Example
Specifying a CRL and Then an OCSP Server: Example
Specifying an OCSP Server: Example
Disabling Nonces in Communications with the OCSP Server: Example
Configuring a Hub Router at a Central Site for Certificate Revocation Checks: Example
Configuring Certificate Authorization and Revocation Settings: Examples
Configuring Certificate Serial Number Session Control
Configuring Certificate Chain Validation: Examples
Configuring Certificate Chain Validation from Peer to Root CA
Configuring Certificate Chain Validation from Peer to Subordinate CA
Configuring Certificate Chain Validation Through a Gap
Configuring Certificate Servers for High Availability: Example
Feature Information for Certificate Authorization and Revocation
Configuring Authorization and Revocation of Certificates in a PKI
First Published: May 2, 2005Last Updated: March 31, 2011This module describes how to configure authorization and revocation of certificates in a public key infrastructure (PKI). It includes information on high-availability support for the certificate server.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Certificate Authorization and Revocation" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Authorization and Revocation of Certificates
•
•
•
•
•
Prerequisites for Authorization and Revocation of Certificates
Plan Your PKI Strategy
Tip
Authorization and revocation can occur only after you or a network administrator have completed the following tasks:
•
•
•
You should decide which authorization and revocation strategy you are going to configure before enrolling peer devices because the peer device certificates might have to contain authorization and revocation-specific information.
"crypto ca" to "crypto pki" CLI Change
As of Cisco IOS Release 12.3(7)T, all commands that begin as "crypto ca" have been changed to begin as "crypto pki." Although the router will still accept crypto ca commands, all output will be read back as crypto pki.
High Availability
For high availability, IPsec-secured Stream Control Transmission Protocol (SCTP) must be configured on both the active and the standby routers. For synchronization to work, the redundancy mode on the certificate servers must be set to ACTIVE/STANDBY after you configure SCTP.
Restrictions for Authorization and Revocation of Certificates
PKI High Availability (HA) support of intra-chassis stateful switchover (SSO) redundancy is currently not supported on all switches running the Cisco IOS Release 12.2 S software. See Cisco bug CSCtb59872 for more information.
Information About Authorization and Revocation of Certificates
Before configuring certificate authorization and revocation, you should understand the following concepts:
•
•
•
•
PKI Authorization
PKI authentication does not provide authorization. Current solutions for authorization are specific to the router that is being configured, although a centrally managed solution is often required.
There is not a standard mechanism by which certificates are defined as authorized for some tasks and not for others. This authorization information can be captured in the certificate itself if the application is aware of the certificate-based authorization information. But this solution does not provide a simple mechanism for real-time updates to the authorization information and forces each application to be aware of the specific authorization information embedded in the certificate.
When the certificate-based ACL mechanism is configured as part of the trustpoint authentication, the application is no longer responsible for determining this authorization information, and it is no longer possible to specify for which application the certificate is authorized. In some cases, the certificate-based ACL on the router gets so large that it cannot be managed. Additionally, it is beneficial to retrieve certificate-based ACL indications from an external server. (For more information on using certificate-based ACLs for authentication, see the section "When to Use Certificate-Based ACLs for Authorization or Revocation.")
Current solutions to the real-time authorization problem involve specifying a new protocol and building a new server (with associated tasks, such as management and data distribution).
PKI and AAA Server Integration for Certificate Status
Integrating your PKI with an authentication, authorization, and accounting (AAA) server provides an alternative online certificate status solution that leverages the existing AAA infrastructure. Certificates can be listed in the AAA database with appropriate levels of authorization. For components that do not explicitly support PKI-AAA, a default label of "all" from the AAA server provides authorization. Likewise, a label of "none" from the AAA database indicates that the specified certificate is not valid. (The absence of any application label is equivalent, but "none" is included for completeness and clarity). If the application component does support PKI-AAA, the component may be specified directly; for example, the application component could be "ipsec," "ssl," or "osp." (ipsec=IP Security, ssl=Secure Sockets Layer, and osp=Open Settlement Protocol.)
Note
•
RADIUS or TACACS+: Choosing a AAA Server Protocol
The AAA server can be configured to work with either the RADIUS or TACACS+ protocol. When you are configuring the AAA server for the PKI integration, you must set the RADIUS or TACACS attributes that are required for authorization.
If the RADIUS protocol is used, the password that is configured for the username in the AAA server should be set to "cisco," which is acceptable because the certificate validation provides authentication and the AAA database is only being used for authorization. When the TACACS protocol is used, the password that is configured for the username in the AAA server is irrelevant because TACACS supports authorization without requiring authentication (the password is used for authentication).
In addition, if you are using TACACS, you must add a PKI service to the AAA server. The custom attribute "cert-application=all" is added under the PKI service for the particular user or usergroup to authorize the specific username.
Attribute-Value Pairs for PKI and AAA Server Integration
Table 1 lists the attribute-value (AV) pairs that are to be used when setting up PKI integration with a AAA server. (Note the values shown in the table are possible values.) The AV pairs must match the client configuration. If they do not match, the peer certificate is not authorized.
Note
CRLs or OCSP Server: Choosing a Certificate Revocation Mechanism
After a certificate is validated as a properly signed certificate, a certificate revocation method is performed to ensure that the certificate has not been revoked by the issuing CA. Cisco IOS software supports two revocation mechanisms—certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP). (Cisco IOS software also supports AAA integration for certificate checking; however, additional authorization functionality is included. For more information on PKI and AAA certificate authorization and status check, see the section "PKI and AAA Server Integration for Certificate Status.")
The following sections explain how each revocation mechanism works:
What Is a CRL?
A certificate revocation list (CRL) is a list of revoked certificates. The CRL is created and digitally signed by the CA that originally issued the certificates. The CRL contains dates for when each certificate was issued and when it expires.
CAs publish new CRLs periodically or when a certificate for which the CA is responsible has been revoked. By default, a new CRL will be downloaded after the currently cached CRL expires. An administrator may also configure the duration for which CRLs are cached in router memory or disable CRL caching completely. The CRL caching configuration will apply to all CRLs associated with a trustpoint.
When the CRL expires, the router deletes it from its cache. A new CRL is downloaded when a certificate is presented for verification; however, if a newer version of the CRL that lists the certificate under examination is on the server but the router is still using the CRL in its cache, the router will not know that the certificate has been revoked. The certificate will pass the revocation check even though it should have been denied.
When a CA issues a certificate, the CA can include in the certificate the CRL distribution point (CDP) for that certificate. Cisco IOS client devices use CDPs to locate and load the correct CRL. The Cisco IOS client supports multiple CDPs, but the Cisco IOS CA currently supports only one CDP; however, third-party vendor CAs may support multiple CDPs or different CDPs per certificate. If a CDP is not specified in the certificate, the client device will use the default Simple Certificate Enrollment Protocol (SCEP) method to retrieve the CRL. (The CDP location can be specified via the cdp-url command.)
When implementing CRLs, you should consider the following design considerations:
•
The CRL lifetime determines the length of time between CA-issued updates to the CRL. (The default CRL lifetime value, which is 168 hours [1 week], can be changed via the lifetime crl command.)
•
–
HTTP, TFTP, and LDAP are the most commonly used methods. Although Cisco IOS software defaults to SCEP, an HTTP CDP is recommended for large installations using CRLs because HTTP can be made highly scalable.
–
Querying All CDPs During Revocation Check
When a CDP server does not respond to a request, the Cisco IOS software reports an error, which may result in the peer's certificate being rejected. To prevent a possible certificate rejection and if there are multiple CDPs in a certificate, the Cisco IOS software will attempt to use the CDPs in the order in which they appear in the certificate. The router will attempt to retrieve a CRL using each CDP URL or directory specification. If an error occurs using a CDP, an attempt will be made using the next CDP.
Note
Tip
What Is OCSP?
OCSP is an online mechanism that is used to determine certificate validity and provides the following flexibility as a revocation mechanism:
•
•
•
•
A network administrator can configure an OCSP server to collect and update CRLs from different CA servers. The devices within the network can rely on the OCSP server to check the certificate status without retrieving and caching each CRL for every peer. When peers have to check the revocation status of a certificate, they send a query to the OCSP server that includes the serial number of the certificate in question and an optional unique identifier for the OCSP request, or a nonce. The OCSP server holds a copy of the CRL to determine if the CA has listed the certificate as being revoked; the server then responds to the peer including the nonce. If the nonce in the response from the OCSP server does not match the original nonce sent by the peer, the response is considered invalid and certificate verification fails. The dialog between the OCSP server and the peer consumes less bandwidth than most CRL downloads.
If the OCSP server is using a CRL, CRL time limitations will be applicable; that is, a CRL that is still valid might be used by the OCSP server although a new CRL has been issued by the CRL containing additional certificate revocation information. Because fewer devices are downloading the CRL information on a regular basis, you can decrease the CRL lifetime value or configure the OCSP server not to cache the CRL. For more information, check your OCSP server documentation.
When to Use an OCSP Server
OCSP may be more appropriate than CRLs if your PKI has any of the following characteristics:
•
•
•
Note
When to Use Certificate-Based ACLs for Authorization or Revocation
Certificates contain several fields that are used to determine whether a device or user is authorized to perform a specified action.
Because certificate-based ACLs are configured on the device, they do not scale well for large numbers of ACLs; however, certificate-based ACLs do provide very granular control of specific device behavior. Certificate-based ACLs are also leveraged by additional features to help determine when PKI components such as revocation, authorization, or a trustpoint should be used. They provide a general mechanism allowing users to select a specific certificate or a group of certificates that are being validated for either authorization or additional processing.
Certificate-based ACLs specify one or more fields within the certificate and an acceptable value for each specified field. You can specify which fields within a certificate should be checked and which values those fields may or may not have.
There are six logical tests for comparing the field with the value—equal, not equal, contains, does not contain, less than, and greater than or equal. If more than one field is specified within a single certificate-based ACL, the tests of all of the fields within the ACL must succeed to match the ACL. The same field may be specified multiple times within the same ACL. More than one ACL may be specified, and ACL will be processed in turn until a match is found or all of the ACLs have been processed.
Ignore Revocation Checks Using a Certificate-Based ACL
Certificate-based ACLs can be configured to instruct your router to ignore the revocation check and expired certificates of a valid peer. Thus, a certificate that meets the specified criteria can be accepted regardless of the validity period of the certificate, or if the certificate meets the specified criteria, revocation checking does not have to be performed. You can also use a certificate-based ACL to ignore the revocation check when the communication with a AAA server is protected with a certificate.
Ignoring Revocation Lists
To allow a trustpoint to enforce CRLs except for specific certificates, enter the match certificate command with the skip revocation-check keyword. This type of enforcement is most useful in a hub-and-spoke configuration in which you also want to allow direct spoke-to-spoke connections. In pure hub-and-spoke configurations, all spokes connect only to the hub, so CRL checking is necessary only on the hub. For one spoke to communicate directly with another spoke, the match certificate command with the skip revocation-check keyword can be used for neighboring peer certificates instead of requiring a CRL on each spoke.
Ignoring Expired Certificates
To configure your router to ignore expired certificates, enter the match certificate command with the allow expired-certificate keyword. This command has the following purposes:
•
•
Note
•
Skipping the AAA Check of the Certificate
If the communication with an AAA server is protected with a certificate, and you want to skip the AAA check of the certificate, use the match certificate command with the skip authorization-check keyword. For example, if a virtual private network (VPN) tunnel is configured so that all AAA traffic goes over that tunnel, and the tunnel is protected with a certificate, you can use the match certificate command with the skip authorization-check keyword to skip the certificate check so that the tunnel can be established.
The match certificate command and the skip authorization-check keyword should be configured after PKI integration with an AAA server is configured.
Note
PKI Certificate Chain Validation
A certificate chain establishes a sequence of trusted certificates —from a peer certificate to the root CA certificate. Within a PKI hierarchy, all enrolled peers can validate the certificate of one another if the peers share a trusted root CA certificate or a common subordinate CA. Each CA corresponds to a trustpoint.
When a certificate chain is received from a peer, the default processing of a certificate chain path continues until the first trusted certificate, or trustpoint, is reached. In Cisco IOS Release 12.4(6)T and later releases, an administrator may configure the level to which a certificate chain is processed on all certificates including subordinate CA certificates.
Configuring the level to which a certificate chain is processed allows for the reauthentication of trusted certificates, the extension of a trusted certificate chain, and the completion of a certificate chain that contains a gap.
Reauthentication of Trusted Certificates
The default behavior is for the router to remove any trusted certificates from the certificate chain sent by the peer before the chain is validated. An administrator may configure certificate chain path processing so that the router does not remove CA certificates that are already trusted before chain validation, so that all certificates in the chain are re-authenticated for the current session.
Extending the Trusted Certificate Chain
The default behavior is for the router to use its trusted certificates to extend the certificate chain if there are any missing certificates in the certificate chain sent by the peer. The router will validate only certificates in the chain sent by the peer. An administrator may configure certificate chain path processing so that the certificates in the peer's certificate chain and the router's trusted certificates are validated to a specified point.
Completing Gaps in a Certificate Chain
An administrator may configure certificate chain processing so that if there is a gap in the configured Cisco IOS trustpoint hierarchy, certificates sent by the peer can be used to complete the set of certificates to be validated.
Note
Note
High-Availability Support
High-availability support for the certificate server is provided by:
•
•
The means that the standby certificate server is ready to issue certificates and certificate revocation lists (CRLs) if it becomes active.
Further high-availability support is provided by the following synchronizations with the standby:
•
•
•
•
•
How to Configure Authorization and Revocation of Certificates for Your PKI
This section contains the following procedures:
•
•
•
•
•
Configuring PKI Integration with a AAA Server
Perform this task to generate a AAA username from the certificate presented by the peer and specify which fields within a certificate should be used to build the AAA database username.
Restrictions When Using the Entire Subject Name for PKI Authorization
The following restrictions should be considered when using the all keyword as the subject name for the authorization username command:
•
•
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
or
radius-server host hostname [key string]
DETAILED STEPS
Troubleshooting Tips
To display debug messages for the trace of interaction (message type) between the CA and the router, use the debug crypto pki transactions command. (See the sample output, which shows a successful PKI integration with AAA server exchange and a failed PKI integration with AAA server exchange.)
Successful Exchange
Router# debug crypto pki transactionsApr 22 23:15:03.695: CRYPTO_PKI: Found a issuer matchApr 22 23:15:03.955: CRYPTO_PKI: cert revocation status unknown.Apr 22 23:15:03.955: CRYPTO_PKI: Certificate validated without revocation checkEach line that shows "CRYPTO_PKI_AAA" indicates the state of the AAA authorization checks. Each of the AAA AV pairs is indicated, and then the results of the authorization check are shown.
Apr 22 23:15:04.019: CRYPTO_PKI_AAA: checking AAA authorization (ipsecca_script_aaalist, PKIAAA-L, <all>)Apr 22 23:15:04.503: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")Apr 22 23:15:04.503: CRYPTO_PKI_AAA: reply attribute ("cert-trustpoint" = "CA1")Apr 22 23:15:04.503: CRYPTO_PKI_AAA: reply attribute ("cert-serial" = "15DE")Apr 22 23:15:04.503: CRYPTO_PKI_AAA: authorization passedApr 22 23:12:30.327: CRYPTO_PKI: Found a issuer matchFailed Exchange
Router# debug crypto pki transactionsApr 22 23:11:13.703: CRYPTO_PKI_AAA: checking AAA authorization =Apr 22 23:11:14.203: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")Apr 22 23:11:14.203: CRYPTO_PKI_AAA: reply attribute ("cert-trustpoint"= "CA1")Apr 22 23:11:14.203: CRYPTO_PKI_AAA: reply attribute ("cert-serial" = "233D")Apr 22 23:11:14.203: CRYPTO_PKI_AAA: parsed cert-lifetime-end as: 21:30:00Apr 22 23:11:14.203: CRYPTO_PKI_AAA: timezone specific extendedApr 22 23:11:14.203: CRYPTO_PKI_AAA: cert-lifetime-end is expiredApr 22 23:11:14.203: CRYPTO_PKI_AAA: cert-lifetime-end check failed.Apr 22 23:11:14.203: CRYPTO_PKI_AAA: authorization failedIn the above failed exchange, the certificate has expired.
Configuring a Revocation Mechanism for PKI Certificate Status Checking
Perform this task to set up a CRL as the certificate revocation mechanism—CRLs or OCSP—that is used to check the status of certificates in a PKI.
The revocation-check Command
Use the revocation-check command to specify at least one method (OCSP, CRL, or skip the revocation check) that is to be used to ensure that the certificate of a peer has not been revoked. For multiple methods, the order in which the methods are applied is determined by the order specified via this command.
If your router does not have the applicable CRL and is unable to obtain one or if the OCSP server returns an error, your router will reject the peer's certificate—unless you include the none keyword in your configuration. If the none keyword is configured, a revocation check will not be performed and the certificate will always be accepted.
Nonces and Peer Communications with OCSP Servers
When using OCSP, nonces, unique identifiers for OCSP requests, are sent by default during peer communications with your OCSP server. The use of nonces offers a more secure and reliable communication channel between the peer and OCSP server.
If your OCSP server does not support nonces, you may disable the sending of nonces. For more information, check your OCSP server documentation.
Prerequisites
•
•
Restrictions
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Configuring Certificate Authorization and Revocation Settings
Perform this task to specify a certificate-based ACL, to ignore revocation checks or expired certificates, to manually override the default CDP location, to manually override the OCSP server setting, to configure CRL caching, or to set session acceptance or rejection based on a certificate serial number, as appropriate.
Configuring Certificate-Based ACLs to Ignore Revocation Checks
To configure your router to use certificate-based ACLs to ignore revocation checks and expired certificates, perform the following steps:
•
•
•
•
Note
Manually Overriding CDPs in a Certificate
Users can override the CDPs in a certificate with a manually configured CDP. Manually overriding the CDPs in a certificate can be advantageous when a particular server is unavailable for an extended period of time. The certificate's CDPs can be replaced with a URL or directory specification without reissuing all of the certificates that contain the original CDP.
Manually Overriding the OCSP Server Setting in a Certificate
Administrators can override the OCSP server setting specified in the Authority Information Access (AIA) field of the client certificate or set by the issuing the ocsp url command. One or more OCSP servers may be manually specified, either per client certificate or per group of client certificates by the match certificate override ocsp command. The match certificate override ocsp command overrides the client certificate AIA field or the ocsp url command setting if a client certificate is successfully matched to a certificate map during the revocation check.
Note
Configuring CRL Cache Control
By default, a new CRL will be downloaded after the currently cached CRL expires. Administrators can either configure the maximum amount of time in minutes a CRL remains in the cache by issuing the crl cache delete-after command or disable CRL caching by issuing the crl cache none command. Only the crl-cache delete-after command or the crl-cache none command may be specified. If both commands are entered for a trustpoint, the last command executed will take effect and a message will be displayed.
Neither the crl-cache none command nor the crl-cache delete-after command affects the currently cached CRL. If you configure the crl-cache none command, all CRLs downloaded after this command is issued will not be cached. If you configure the crl-cache delete-after command, the configured lifetime will only affect CRLs downloaded after this command is issued.
This functionality is useful is when a CA issues CRLs with no expiration date or with expiration dates days or weeks ahead.
Configuring Certificate Serial Number Session Control
A certificate serial number can be specified to allow a certificate validation request to be accepted or rejected by the trustpoint for a session. A session may be rejected, depending on certificate serial number session control, even if a certificate is still valid. Certificate serial number session control may be configured by using either a certificate map with the serial-number field or an AAA attribute, with the cert-serial-not command.
Using certificate maps for session control allows an administrator to specify a single certificate serial number. Using the AAA attribute allows an administrator to specify one or more certificate serial numbers for session control.
Prerequisites
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
or
crl-cache delete-after time
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
DETAILED STEPS
Examples
The following is a sample certificate. The OCSP-related extensions are shown using exclamation points.
Certificate:Data:Version: v3Serial Number:0x14Signature Algorithm:MD5withRSA - 1.2.840.113549.1.1.4Issuer:CN=CA server,OU=PKI,O=Cisco SystemsValidity:Not Before:Thursday, August 8, 2002 4:38:05 PM PSTNot After:Tuesday, August 7, 2003 4:38:05 PM PSTSubject:CN=OCSP server,OU=PKI,O=Cisco SystemsSubject Public Key Info:Algorithm:RSA - 1.2.840.113549.1.1.1Public Key:Exponent:65537Public Key Modulus:(1024 bits) :<snip>Extensions:Identifier:Subject Key Identifier - 2.5.29.14Critical:noKey Identifier:<snip>Identifier:Authority Key Identifier - 2.5.29.35Critical:noKey Identifier:<snip>! Identifier:OCSP NoCheck:- 1.3.6.1.5.5.7.48.1.5Critical:noIdentifier:Extended Key Usage:- 2.5.29.37Critical:noExtended Key Usage:OCSPSigning!Identifier:CRL Distribution Points - 2.5.29.31Critical:noNumber of Points:1Point 0Distribution Point:[URIName:ldap://CA-server/CN=CA server,OU=PKI,O=Cisco Systems]Signature:Algorithm:MD5withRSA - 1.2.840.113549.1.1.4Signature:<snip>The following example shows an excerpt of the running configuration output when adding a match certificate override ocsp command to the beginning of an existing sequence:
match certificate map3 override ocsp 5 url http://192.0.2.3/show running-configuration...match certificate map3 override ocsp 5 url http://192.0.2.3/match certificate map1 override ocsp 10 url http://192.0.2.1/match certificate map2 override ocsp 15 url http://192.0.2.2/The following example shows an excerpt of the running configuration output when an existing match certificate override ocsp command is replaced and a trustpoint is specified to use an alternative PKI hierarchy:
match certificate map4 override ocsp trustpoint tp4 10 url http://192.0.2.4/newvalueshow running-configuration...match certificate map3 override ocsp trustpoint tp3 5 url http://192.0.2.3/match certificate map1 override ocsp trustpoint tp1 10 url http://192.0.2.1/match certificate map4 override ocsp trustpoint tp4 10 url http://192.0.2.4/newvaluematch certificate map2 override ocsp trustpoint tp2 15 url http://192.0.2.2/Troubleshooting Tips
If you ignored revocation check or expired certificates, you should carefully check your configuration. Verify that the certificate map properly matches either the certificate or certificates that should be allowed or the AAA checks that should be skipped. In a controlled environment, try modifying the certificate map and determine what is not working as expected.
Configuring Certificate Chain Validation
Perform this task to configure the processing level for the certificate chain path of your peer certificates.
Prerequisites
•
•
Restrictions
•
The chain-validation command is configured with the continue keyword for the trustpoint associated with the root CA, an error message will be displayed and the chain validation will revert to the default chain-validation command setting.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Certificate Servers for
High AvailabilityYou can configure certificate servers to synchronize revoke commands and send serial-number commands when new certificates are issued, preparing the standby certificate server to issue certificates and CRLs if it becomes active.
Prerequisites
The following conditions must be met for high availability on certificate servers:
•
•
This section contains the following subsections:
•
•
•
Configuring SCTP on the Active and Standby Certificate Servers
Perform this task on the active router to configure SCTP on both the active and the standby certificate server.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
Setting Redundancy Mode on Certificate Servers to ACTIVE/STANDBY
Perform this task on the active router to enable synchronization by setting the redundancy mode on the certificate servers to ACTIVE/STANDBY.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
DETAILED STEPS
Synchronizing the Active and Standby Certificate Servers
Perform this task to synchronize the active and standby servers.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Configuration Examples for Setting Up Authorization and Revocation of Certificates
This section contains the following configuration examples:
•
•
•
•
•
•
Configuring and Verifying PKI AAA Authorization: Examples
This section provides configuration examples of PKI AAA authorizations:
•
•
•
Router Configuration: Example
The following show running-config command output shows the working configuration of a router that is set up to authorize VPN connections using the PKI Integration with AAA Server feature:
Router# show running-configBuilding configuration...!version 12.3!hostname router7200router7200!aaa new-model!!aaa authentication login default group tacacs+aaa authentication login no_tacacs enableaaa authentication ppp default group tacacs+aaa authorization exec ACSLab group tacacs+aaa authorization network ACSLab group tacacs+aaa accounting exec ACSLab start-stop group tacacs+aaa accounting network default start-stop group ACSLabaaa session-id common!ip domain name example.com!crypto pki trustpoint EM-CERT-SERVenrollment url http://192.0.2.33:80serial-numbercrl optionalrsakeypair STOREVPN 1024auto-enrollauthorization list ACSLab!crypto pki certificate chain EM-CERT-SERVcertificate 0430820214 3082017D A0030201 02020104 300D0609 2A864886 F70D0101 0405003017311530 13060355 0403130C 454D2D43 4552542D 53455256 301E170D 3034303131393232 30323535 5A170D30 35303131 38323230 3235355A 3030312E 300E060355040513 07314437 45424434 301C0609 2A864886 F70D0109 02160F37 3230302D312E6772 696C2E63 6F6D3081 9F300D06 092A8648 86F70D01 01010500 03818D0030818902 818100BD F3B837AA D925F391 2B64DA14 9C2EA031 5A7203C4 92F8D6A87D2357A6 BCC8596F A38A9B10 47435626 D59A8F2A 123195BB BE5A1E74 B1AA5AE05CA162FF 8C3ACA4F B3EE9F27 8B031642 B618AE1B 40F2E3B4 F996BEFE 382C72833792A369 236F8561 8748AA3F BC41F012 B859BD9C DB4F75EE 3CEE2829 704BD68FFD904043 0F555702 03010001 A3573055 30250603 551D1F04 1E301C30 1AA018A016861468 7474703A 2F2F3633 2E323437 2E313037 2E393330 0B060355 1D0F0404030205A0 301F0603 551D2304 18301680 1420FC4B CF0B1C56 F5BD4C06 0AFD4E67341AE612 D1300D06 092A8648 86F70D01 01040500 03818100 79E97018 FB95510812F42A56 2A6384BC AC8E22FE F1D6187F DA5D6737 C0E241AC AAAEC75D 3C743F5908DEEFF2 0E813A73 D79E0FA9 D62DC20D 8E2798CD 2C1DC3EC 3B2505A1 3897330C15A60D5A 8A13F06D 51043D37 E56E45DF A65F43D7 4E836093 9689784D C45FD61DEC1F160C 1ABC8D03 49FB11B1 DA0BED6C 463E1090 F34C59E4quitcertificate ca 0130820207 30820170 A0030201 02020101 300D0609 2A864886 F70D0101 0405003017311530 13060355 0403130C 454D2D43 4552542D 53455256 301E170D 3033313231363231 34373432 5A170D30 36313231 35323134 3734325A 30173115 3013060355040313 0C454D2D 43455254 2D534552 5630819F 300D0609 2A864886 F70D010101050003 818D0030 81890281 8100C14D 833641CF D784F516 DA6B50C0 7B3CB3C9589223AB 99A7DC14 04F74EF2 AAEEE8F5 E3BFAE97 F2F980F7 D889E6A1 2C726C6954A29870 7E7363FF 3CD1F991 F5A37CFF 3FFDD3D0 9E486C44 A2E34595 C2D078BBE9DE981E B733B868 AA8916C0 A8048607 D34B83C0 64BDC101 161FC103 13C0650022D6EE75 7D6CF133 7F1B515F 32830203 010001A3 63306130 0F060355 1D130101FF040530 030101FF 300E0603 551D0F01 01FF0404 03020186 301D0603 551D0E0416041420 FC4BCF0B 1C56F5BD 4C060AFD 4E67341A E612D130 1F060355 1D23041830168014 20FC4BCF 0B1C56F5 BD4C060A FD4E6734 1AE612D1 300D0609 2A864886F70D0101 04050003 81810085 D2E386F5 4107116B AD3AC990 CBE84063 5FB2A6B5BD572026 528E92ED 02F3A0AE 1803F2AE AA4C0ED2 0F59F18D 7B50264F 30442C410AF19C4E 70BD3CB5 0ADD8DE8 8EF636BD 24410DF4 DB62DAFC 67DA6E58 3879AA3E12AFB1C3 2E27CB27 EC74E1FC AEE2F5CF AA80B439 615AA8D5 6D6DEDC3 7F9C2C793963E363 F2989FB9 795BA8quit!!crypto isakmp policy 10encr 3desgroup 2!!crypto ipsec transform-set ISC_TS_1 esp-3des esp-sha-hmac!crypto ipsec profile ISC_IPSEC_PROFILE_2set security-association lifetime kilobytes 530000000set security-association lifetime seconds 14400set transform-set ISC_TS_1!!controller ISA 1/1!!interface Tunnel0description MGRE Interface provisioned by ISCbandwidth 10000ip address 192.0.2.172 255.255.255.0no ip redirectsip mtu 1408ip nhrp map multicast dynamicip nhrp network-id 101ip nhrp holdtime 500ip nhrp server-onlyno ip split-horizon eigrp 101tunnel source FastEthernet2/1tunnel mode gre multipointtunnel key 101tunnel protection ipsec profile ISC_IPSEC_PROFILE_2!interface FastEthernet2/0ip address 192.0.2.1 255.255.255.0duplex autospeed auto!interface FastEthernet2/1ip address 192.0.2.2 255.255.255.0duplex autospeed auto!!tacacs-server host 192.0.2.55 single-connectiontacacs-server directed-requesttacacs-server key company lab!ntp master 1!endDebug of a Successful PKI AAA Authorization: Example
The following show debugging command output shows a successful authorization using the PKI Integration with AAA Server feature:
Router# show debuggingGeneral OS:TACACS access control debugging is onAAA Authentication debugging is onAAA Authorization debugging is onCryptographic Subsystem:Crypto PKI Trans debugging is onRouter#May 28 19:36:11.117: CRYPTO_PKI: Trust-Point EM-CERT-SERV picked upMay 28 19:36:12.789: CRYPTO_PKI: Found a issuer matchMay 28 19:36:12.805: CRYPTO_PKI: cert revocation status unknown.May 28 19:36:12.805: CRYPTO_PKI: Certificate validated without revocation checkMay 28 19:36:12.813: CRYPTO_PKI_AAA: checking AAA authorization (ACSLab, POD5.example.com, <all>)May 28 19:36:12.813: AAA/BIND(00000042): Bind i/fMay 28 19:36:12.813: AAA/AUTHOR (0x42): Pick method list 'ACSLab'May 28 19:36:12.813: TPLUS: Queuing AAA Authorization request 66 for processingMay 28 19:36:12.813: TPLUS: processing authorization request id 66May 28 19:36:12.813: TPLUS: Protocol set to None .....SkippingMay 28 19:36:12.813: TPLUS: Sending AV service=pkiMay 28 19:36:12.813: TPLUS: Authorization request created for 66(POD5.example.com)May 28 19:36:12.813: TPLUS: Using server 192.0.2.55May 28 19:36:12.813: TPLUS(00000042)/0/NB_WAIT/203A4628: Started 5 sec timeoutMay 28 19:36:12.813: TPLUS(00000042)/0/NB_WAIT: wrote entire 46 bytes requestMay 28 19:36:12.813: TPLUS: Would block while reading pak headerMay 28 19:36:12.817: TPLUS(00000042)/0/READ: read entire 12 header bytes (expect 27 bytes)May 28 19:36:12.817: TPLUS(00000042)/0/READ: read entire 39 bytes responseMay 28 19:36:12.817: TPLUS(00000042)/0/203A4628: Processing the reply packetMay 28 19:36:12.817: TPLUS: Processed AV cert-application=allMay 28 19:36:12.817: TPLUS: received authorization response for 66: PASSMay 28 19:36:12.817: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")May 28 19:36:12.817: CRYPTO_PKI_AAA: authorization passedRouter#Router#May 28 19:36:18.681: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 101: Neighbor 192.0.2.171 (Tunnel0) is up: new adjacencyRouter#Router# show crypto isakmp sadst src state conn-id slot192.0.2.22 192.0.2.102 QM_IDLE 84 0Debugs of a Failed PKI AAA Authorization: Example
The following show debugging command output shows that the router is not authorized to connect using VPN. The messages are typical of those that you might see in such a situation.
In this example, the peer username was configured as not authorized, by moving the username to a Cisco Secure ACS group called VPN_Router_Disabled in Cisco Secure ACS. The router, router7200.example.com, has been configured to check with a Cisco Secure ACS AAA server prior to establishing a VPN connection to any peer.
Router# show debuggingGeneral OS:TACACS access control debugging is onAAA Authentication debugging is onAAA Authorization debugging is onCryptographic Subsystem:Crypto PKI Trans debugging is onRouter#May 28 19:48:29.837: CRYPTO_PKI: Trust-Point EM-CERT-SERV picked upMay 28 19:48:31.509: CRYPTO_PKI: Found a issuer matchMay 28 19:48:31.525: CRYPTO_PKI: cert revocation status unknown.May 28 19:48:31.525: CRYPTO_PKI: Certificate validated without revocation checkMay 28 19:48:31.533: CRYPTO_PKI_AAA: checking AAA authorization (ACSLab, POD5.example.com, <all>)May 28 19:48:31.533: AAA/BIND(00000044): Bind i/fMay 28 19:48:31.533: AAA/AUTHOR (0x44): Pick method list 'ACSLab'May 28 19:48:31.533: TPLUS: Queuing AAA Authorization request 68 for processingMay 28 19:48:31.533: TPLUS: processing authorization request id 68May 28 19:48:31.533: TPLUS: Protocol set to None .....SkippingMay 28 19:48:31.533: TPLUS: Sending AV service=pkiMay 28 19:48:31.533: TPLUS: Authorization request created for 68(POD5.example.com)May 28 19:48:31.533: TPLUS: Using server 192.0.2.55May 28 19:48:31.533: TPLUS(00000044)/0/NB_WAIT/203A4C50: Started 5 sec timeoutMay 28 19:48:31.533: TPLUS(00000044)/0/NB_WAIT: wrote entire 46 bytes requestMay 28 19:48:31.533: TPLUS: Would block while reading pak headerMay 28 19:48:31.537: TPLUS(00000044)/0/READ: read entire 12 header bytes (expect 6 bytes)May 28 19:48:31.537: TPLUS(00000044)/0/READ: read entire 18 bytes responseMay 28 19:48:31.537: TPLUS(00000044)/0/203A4C50: Processing the reply packetMay 28 19:48:31.537: TPLUS: received authorization response for 68: FAILMay 28 19:48:31.537: CRYPTO_PKI_AAA: authorization declined by AAA, or AAA server not found.May 28 19:48:31.537: CRYPTO_PKI_AAA: No cert-application attribute found. Failing.May 28 19:48:31.537: CRYPTO_PKI_AAA: authorization failedMay 28 19:48:31.537: CRYPTO_PKI: AAA authorization for list 'ACSLab', and user 'POD5.example.com' failed.May 28 19:48:31.537: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 192.0.2.162 is bad: certificate invalidMay 28 19:48:39.821: CRYPTO_PKI: Trust-Point EM-CERT-SERV picked upMay 28 19:48:41.481: CRYPTO_PKI: Found a issuer matchMay 28 19:48:41.501: CRYPTO_PKI: cert revocation status unknown.May 28 19:48:41.501: CRYPTO_PKI: Certificate validated without revocation checkMay 28 19:48:41.505: CRYPTO_PKI_AAA: checking AAA authorization (ACSLab, POD5.example.com, <all>)May 28 19:48:41.505: AAA/BIND(00000045): Bind i/fMay 28 19:48:41.505: AAA/AUTHOR (0x45): Pick method list 'ACSLab'May 28 19:48:41.505: TPLUS: Queuing AAA Authorization request 69 for processingMay 28 19:48:41.505: TPLUS: processing authorization request id 69May 28 19:48:41.505: TPLUS: Protocol set to None .....SkippingMay 28 19:48:41.505: TPLUS: Sending AV service=pkiMay 28 19:48:41.505: TPLUS: Authorization request created for 69(POD5.example.com)May 28 19:48:41.505: TPLUS: Using server 198.168.244.55May 28 19:48:41.509: TPLUS(00000045)/0/IDLE/63B22834: got immediate connect on new 0May 28 19:48:41.509: TPLUS(00000045)/0/WRITE/63B22834: Started 5 sec timeoutMay 28 19:48:41.509: TPLUS(00000045)/0/WRITE: wrote entire 46 bytes requestMay 28 19:48:41.509: TPLUS(00000045)/0/READ: read entire 12 header bytes (expect 6 bytes)May 28 19:48:41.509: TPLUS(00000045)/0/READ: read entire 18 bytes responseMay 28 19:48:41.509: TPLUS(00000045)/0/63B22834: Processing the reply packetMay 28 19:48:41.509: TPLUS: received authorization response for 69: FAILMay 28 19:48:41.509: CRYPTO_PKI_AAA: authorization declined by AAA, or AAA server not found.May 28 19:48:41.509: CRYPTO_PKI_AAA: No cert-application attribute found. Failing.May 28 19:48:41.509: CRYPTO_PKI_AAA: authorization failedMay 28 19:48:41.509: CRYPTO_PKI: AAA authorization for list 'ACSLab', and user 'POD5.example.com' failed.May 28 19:48:41.509: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 192.0.2.162 is bad: certificate invalidRouter#Router# show crypto iskmp sadst src state conn-id slot192.0.2.2 192.0.2.102 MM_KEY_EXCH 95 0Configuring a Revocation Mechanism: Examples
This section contains the following configuration examples that can be used when specifying a revocation mechanism for your PKI:
•
•
•
•
Configuring an OCSP Server: Example
The following example shows how to configure the router to use the OCSP server that is specified in the AIA extension of the certificate:
Router(config)# crypto pki trustpoint mytpRouter(ca-trustpoint)# revocation-check ocspSpecifying a CRL and Then an OCSP Server: Example
The following example shows how to configure the router to download the CRL from the CDP. If the CRL is unavailable, the OCSP server that is specified in the AIA extension of the certificate will be used. If both options fail, certificate verification will also fail.
Router(config)# crypto pki trustpoint mytpRouter(ca-trustpoint)# revocation-check crl ocspSpecifying an OCSP Server: Example
The following example shows how to configure your router to use the OCSP server at the HTTP URL "http://myocspserver:81." If the server is down, the revocation check will be ignored.
Router(config)# crypto pki trustpoint mytpRouter(ca-trustpoint)# ocsp url http://myocspserver:81Router(ca-trustpoint)# revocation-check ocsp noneDisabling Nonces in Communications with the OCSP Server: Example
The following example shows communications when a nonce, or a unique identifier for the OCSP request, is disabled for communications with the OCSP server:
Router(config)# crypto pki trustpoint mytpRouter(ca-trustpoint)# ocsp url http://myocspserver:81Router(ca-trustpoint)# revocation-check ocsp noneRouter(ca-trustpoint)# ocsp disable-nonceConfiguring a Hub Router at a Central Site for Certificate Revocation Checks: Example
The following example shows a hub router at a central site that is providing connectivity for several branch offices to the central site.
The branch offices are also able to communicate directly with each other using additional IPSec tunnels between the branch offices.
The CA publishes CRLs on an HTTP server at the central site. The central site checks CRLs for each peer when setting up an IPSec tunnel with that peer.
The example does not show the IPSec configuration—only the PKI-related configuration is shown.
Home Office Hub Configuration
crypto pki trustpoint VPN-GWenrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dllserial-number nonefqdn noneip-address nonesubject-name o=Home Office Inc,cn=Central VPN Gatewayrevocation-check crlCentral Site Hub Router
Router# show crypto ca certificateCertificateStatus: AvailableCertificate Serial Number: 2F62BE14000000000CA0Certificate Usage: General PurposeIssuer:cn=Central Certificate Authorityo=Home Office IncSubject:Name: Central VPN Gatewaycn=Central VPN Gatewayo=Home Office IncCRL Distribution Points:http://ca.home-office.com/CertEnroll/home-office.crlValidity Date:start date: 00:43:26 GMT Sep 26 2003end date: 00:53:26 GMT Sep 26 2004renew date: 00:00:00 GMT Jan 1 1970Associated Trustpoints: VPN-GWCA CertificateStatus: AvailableCertificate Serial Number: 1244325DE0369880465F977A18F61CA8Certificate Usage: SignatureIssuer:cn=Central Certificate Authorityo=Home Office IncSubject:cn=Central Certificate Authorityo=Home Office IncCRL Distribution Points:http://ca.home-office.com/CertEnroll/home-office.crlValidity Date:start date: 22:19:29 GMT Oct 31 2002end date: 22:27:27 GMT Oct 31 2017Associated Trustpoints: VPN-GWTrustpoint on the Branch Office Router
crypto pki trustpoint home-officeenrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dllserial-number nonefqdn noneip-address nonesubject-name o=Home Office Inc,cn=Branch 1revocation-check crlA certificate map is entered on the branch office router.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.branch1(config)# crypto pki certificate map central-site 10branch1(ca-certificate-map)#The output from the show certificate command on the central site hub router shows that the certificate was issued by the following:
cn=Central Certificate Authorityo=Home Office IncThese two lines are combined into one line using a comma (,) to separate them, and the original lines are added as the first criteria for a match.
Router (ca-certificate-map)# issuer-name co cn=Central Certificate Authority, ou=Home Office Inc!The above line wrapped but should be shown on one line with the line above it.The same combination is done for the subject name from the certificate on the central site router (note that the line that begins with "Name:" is not part of the subject name and must be ignored when creating the certificate map criteria). This is the subject name to be used in the certificate map.
cn=Central VPN Gateway
o=Home Office Inc
Router (ca-certificate-map)# subject-name eq cn=central vpn gateway, o=home office incNow the certificate map is added to the trustpoint that was configured earlier.
Router (ca-certificate-map)# crypto pki trustpoint home-officeRouter (ca-trustpoint)# match certificate central-site skip revocation-checkRouter (ca-trustpoint)# exitRouter (config)# exitThe configuration is checked (most of configuration is not shown).
Router# write term!Many lines left out...crypto pki trustpoint home-officeenrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dllserial-number nonefqdn noneip-address nonesubject-name o=Home Office Inc,cn=Branch 1revocation-check crlmatch certificate central-site skip revocation-check!!crypto pki certificate map central-site 10issuer-name co cn = Central Certificate Authority, ou = Home Office Incsubject-name eq cn = central vpn gateway, o = home office inc!many lines left outNote that the issuer-name and subject-name lines have been reformatted to make them consistent for later matching with the certificate of the peer.
If the branch office is checking the AAA, the trustpoint will have lines similar to the following:
crypto pki trustpoint home-officeauth list allow_listauth user subj commonnameAfter the certificate map has been defined as was done above, the following command is added to the trustpoint to skip AAA checking for the central site hub.
match certificate central-site skip authorization-checkIn both cases, the branch site router has to establish an IPSec tunnel to the central site to check CRLs or to contact the AAA server. However, without the match certificate command and central-site skip authorization-check (argument and keyword), the branch office cannot establish the tunnel until it has checked the CRL or the AAA server. (The tunnel will not be established unless the match certificate command and central-site skip authorization-check argument and keyword are used.)
The match certificate command and allow expired-certificate keyword would be used at the central site if the router at a branch site had an expired certificate and it had to establish a tunnel to the central site to renew its certificate.
Trustpoint on the Central Site Router
crypto pki trustpoint VPN-GWenrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dllserial-number nonefqdn noneip-address nonesubject-name o=Home Office Inc,cn=Central VPN Gatewayrevocation-check crlTrustpoint on the Branch 1 Site Router
Router# show crypto ca certificateCertificateStatus: AvailableCertificate Serial Number: 2F62BE14000000000CA0Certificate Usage: General PurposeIssuer:cn=Central Certificate Authorityo=Home Office IncSubject:Name: Branch 1 Sitecn=Branch 1 Siteo=Home Office IncCRL Distribution Points:http://ca.home-office.com/CertEnroll/home-office.crlValidity Date:start date: 00:43:26 GMT Sep 26 2003end date: 00:53:26 GMT Oct 3 2003renew date: 00:00:00 GMT Jan 1 1970Associated Trustpoints: home-officeCA CertificateStatus: AvailableCertificate Serial Number: 1244325DE0369880465F977A18F61CA8Certificate Usage: SignatureIssuer:cn=Central Certificate Authorityo=Home Office IncSubject:cn=Central Certificate Authorityo=Home Office IncCRL Distribution Points:http://ca.home-office.com/CertEnroll/home-office.crlValidity Date:start date: 22:19:29 GMT Oct 31 2002end date: 22:27:27 GMT Oct 31 2017Associated Trustpoints: home-officeA certificate map is entered on the central site router.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router (config)# crypto pki certificate map branch1 10Router (ca-certificate-map)# issuer-name co cn=Central Certificate Authority, ou=Home Office Inc!The above line wrapped but should be part of the line above it.Router (ca-certificate-map)# subject-name eq cn=Brahcn 1 Site,o=home office incThe certificate map is added to the trustpoint.
Router (ca-certificate-map)# crypto pki trustpoint VPN-GWRouter (ca-trustpoint)# match certificate branch1 allow expired-certificateRouter (ca-trustpoint)# exitRouter (config) #exitThe configuration should be checked (most of the configuration is not shown).
Router# write term!many lines left outcrypto pki trustpoint VPN-GWenrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dllserial-number nonefqdn noneip-address nonesubject-name o=Home Office Inc,cn=Central VPN Gatewayrevocation-check crlmatch certificate branch1 allow expired-certificate!!crypto pki certificate map central-site 10issuer-name co cn = Central Certificate Authority, ou = Home Office Incsubject-name eq cn = central vpn gateway, o = home office inc! many lines left outThe match certificate command and branch1 allow expired-certificate (argument and keyword) and the certificate map should be removed as soon as the branch router has a new certificate.
Configuring Certificate Authorization and Revocation Settings: Examples
This section contains the following configuration examples that can be used when specifying a CRL cache control setting or certificate serial number session control:
•
•
Configuring CRL Cache Control
The following example shows how to disable CRL caching for all CRLs associated with the CA1 trustpoint:
crypto pki trustpoint CA1enrollment url http://CA1:80ip-address FastEthernet0/0crl query ldap://ldap_CA1revocation-check crlcrl-cache noneThe current CRL is still cached immediately after executing the example configuration shown above:
Router# show crypto pki crls
CRL Issuer Name:cn=name Cert Manager,ou=pki,o=example.com,c=USLastUpdate: 18:57:42 GMT Nov 26 2005NextUpdate: 22:57:42 GMT Nov 26 2005Retrieved from CRL Distribution Point:ldap://ldap.example.com/CN=name Cert Manager,O=example.comWhen the current CRL expires, a new CRL is then downloaded to the router at the next update. The crl-cache none command takes effect and all CRLs for the trustpoint are no longer cached; caching is disabled. You can verify that no CRL is cached by executing the show crypto pki crls command. No output will be shown because there are no CRLs cached.
The following example shows how to configure the maximum lifetime of 2 minutes for all CRLs associated with the CA1 trustpoint:
crypto pki trustpoint CA1enrollment url http://CA1:80ip-address FastEthernet0/0crl query ldap://ldap_CA1revocation-check crlcrl-cache delete-after 2The current CRL is still cached immediately after executing the example configuration above for setting the maximum lifetime of a CRL:
Router# show crypto pki crls
CRL Issuer Name:cn=name Cert Manager,ou=pki,o=example.com,c=USLastUpdate: 18:57:42 GMT Nov 26 2005NextUpdate: 22:57:42 GMT Nov 26 2005Retrieved from CRL Distribution Point:ldap://ldap.example.com/CN=name Cert Manager,O=example.comWhen the current CRL expires, a new CRL is downloaded to the router at the next update and the crl-cache delete-after command takes effect. This newly cached CRL and all subsequent CRLs will be deleted after a maximum lifetime of 2 minutes.You can verify that the CRL will be cached for 2 minutes by executing the show crypto pki crls command. Note that the NextUpdate time is 2 minutes after the LastUpdate time.Router# show crypto pki crls
CRL Issuer Name:cn=name Cert Manager,ou=pki,o=example.com,c=USLastUpdate: 22:57:42 GMT Nov 26 2005NextUpdate: 22:59:42 GMT Nov 26 2005Retrieved from CRL Distribution Point:ldap://ldap.example.com/CN=name Cert Manager,O=example.com
Configuring Certificate Serial Number Session Control
The following example shows the configuration of certificate serial number session control using a certificate map for the CA1 trustpoint:
crypto pki trustpoint CA1enrollment url http://CA1chain-validation stopcrl query ldap://ldap_serverrevocation-check crlmatch certificate crl!crypto pki certificate map crl 10serial-number co 279d
Note
The following example shows the configuration of certificate serial number session control using AAA attributes. In this case, all valid certificates will be accepted if the certificate does not have the serial number "4ACA."
crypto pki trustpoint CA1enrollment url http://CA1ip-address FastEthernet0/0crl query ldap://ldap_CA1revocation-check crlaaa new-model!aaa attribute list crlattribute-type aaa-cert-serial-not 4ACAThe server log shows that the certificate with the serial number "4ACA" was rejected. The certificate rejection is shown using exclamation points.
...Dec 3 04:24:39.051: CRYPTO_PKI: Trust-Point CA1 picked upDec 3 04:24:39.051: CRYPTO_PKI: locked trustpoint CA1, refcount is 1Dec 3 04:24:39.051: CRYPTO_PKI: unlocked trustpoint CA1, refcount is 0Dec 3 04:24:39.051: CRYPTO_PKI: locked trustpoint CA1, refcount is 1Dec 3 04:24:39.135: CRYPTO_PKI: validation path has 1 certsDec 3 04:24:39.135: CRYPTO_PKI: Found a issuer matchDec 3 04:24:39.135: CRYPTO_PKI: Using CA1 to validate certificateDec 3 04:24:39.135: CRYPTO_PKI: Certificate validated without revocation checkDec 3 04:24:39.135: CRYPTO_PKI: Selected AAA username: 'PKIAAA'Dec 3 04:24:39.135: CRYPTO_PKI: Anticipate checking AAA list:'CRL'Dec 3 04:24:39.135: CRYPTO_PKI_AAA: checking AAA authorization (CRL, PKIAAA-L1, <all>)Dec 3 04:24:39.135: CRYPTO_PKI_AAA: pre-authorization chain validation status (0x4)Dec 3 04:24:39.135: AAA/BIND(00000021): Bind i/fDec 3 04:24:39.135: AAA/AUTHOR (0x21): Pick method list 'CRL'...Dec 3 04:24:39.175: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")Dec 3 04:24:39.175: CRYPTO_PKI_AAA: reply attribute ("cert-trustpoint" = "CA1")!Dec 3 04:24:39.175: CRYPTO_PKI_AAA: reply attribute ("cert-serial-not" = "4ACA")Dec 3 04:24:39.175: CRYPTO_PKI_AAA: cert-serial doesn't match ("4ACA" != "4ACA")!Dec 3 04:24:39.175: CRYPTO_PKI_AAA: post-authorization chain validation status (0x7)!Dec 3 04:24:39.175: CRYPTO_PKI: AAA authorization for list 'CRL', and user 'PKIAAA' failed.Dec 3 04:24:39.175: CRYPTO_PKI: chain cert was anchored to trustpoint CA1, and chain validation result was: CRYPTO_PKI_CERT_NOT_AUTHORIZED!Dec 3 04:24:39.175: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 192.0.2.43 is bad: certificate invalidDec 3 04:24:39.175: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer at 192.0.2.43...Configuring Certificate Chain Validation: Examples
This section contains the following configuration examples that can be used to specify the level of certificate chain processing for your device certificates:
•
•
•
Configuring Certificate Chain Validation from Peer to Root CA
In the following configuration example, all of the certificates will be validated—the peer, SubCA11, SubCA1, and RootCA certificates.
crypto pki trustpoint RootCAenrollment terminalchain-validation stoprevocation-check nonersakeypair RootCAcrypto pki trustpoint SubCA1enrollment terminalchain-validation continue RootCArevocation-check nonersakeypair SubCA1crypto pki trustpoint SubCA11enrollment terminalchain-validation continue SubCA1revocation-check nonersakeypair SubCA11Configuring Certificate Chain Validation from Peer to Subordinate CA
In the following configuration example, the following certificates will be validated—the peer and SubCA1 certificates.
crypto pki trustpoint RootCAenrollment terminalchain-validation stoprevocation-check nonersakeypair RootCAcrypto pki trustpoint SubCA1enrollment terminalchain-validation continue RootCArevocation-check nonersakeypair SubCA1crypto pki trustpoint SubCA11enrollment terminalchain-validation continue SubCA1revocation-check nonersakeypair SubCA11Configuring Certificate Chain Validation Through a Gap
In the following configuration example, SubCA1 is not in the configured Cisco IOS hierarchy but is expected to have been supplied in the certificate chain presented by the peer.
If the peer supplies the SubCA1 certificate in the presented certificate chain, the following certificates will be validated—the peer, SubCA11, and SubCA1 certificates.
If the peer does not supply the SubCA1 certificate in the presented certificate chain, the chain validation will fail.
crypto pki trustpoint RootCAenrollment terminalchain-validation stoprevocation-check nonersakeypair RootCAcrypto pki trustpoint SubCA11enrollment terminalchain-validation continue RootCArevocation-check nonersakeypair SubCA11Configuring Certificate Servers for
High Availability: ExampleThe following example shows the configuration of SCTP and redundancy on the active and the standby certificate server, and activation of synchronization betwen them:
On the Active Router
ipc zone defaultassociation 1no shutdownprotocol sctplocal-port 5000local-ip 10.0.0.1exitremote-port 5000remote-ip 10.0.0.2On the Standby Router
ipc zone defaultassociation 1no shutdownprotocol sctplocal-port 5000local-ip 10.0.0.2exitremote-port 5000remote-ip 10.0.0.1On the Active Router
redundancy inter-devicescheme standby SBinterface GigabitEthernet0/1ip address 10.0.0.1 255.255.255.0no ip route-cache cefno ip route-cachestandby 0 ip 10.0.0.3standby 0 priority 50standby 0 name SBstandby delay min 30 reload 60On the Standby Router
redundancy inter-devicescheme standby SBinterface GigabitEthernet0/1ip address 10.0.0.2 255.255.255.0no ip route-cache cefno ip route-cachestandby 0 ip 10.0.0.3standby 0 priority 50standby 0 name SBstandby delay min 30 reload 60On the Active Router
crypto pki server mycertsavercrypto pki server mycertsaver redundancyAdditional References
Related Documents
PKI commands: complete command syntax, command mode, defaults, usage guidelines, and examples
Overview of PKI, including RSA keys, certificate enrollment, and CAs
"Cisco IOS PKI Overview: Understanding and Planning a PKI" module
RSA key generation and deployment
"Deploying RSA Keys Within a PKI" module
Certificate enrollment: supported methods, enrollment profiles, configuration tasks
Cisco IOS certificate server overview information and configuration tasks
"Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment" module
Technical Assistance
Feature Information for Certificate Authorization and Revocation
Table 2 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 2 Feature Information for PKI Certificate Authorization and Revocation
Cache Control Enhancements for Certification Revocation Lists
12.4(9)T
This feature provides users the ability to disable CRL caching or to specify the maximum lifetime for which a CRL will be cached in router memory. It also provides functionality to configure certificate serial number session control.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: crl-cache delete-after, crl-cache none, crypto pki certificate map
Certificate-Complete Chain Validation
12.4(6)T
This feature provides users the ability to configure the level to which a certificate chain is processed on all certificates including subordinate CA certificates.
The following sections provide information about this feature:
•
•
•
The following command was introduced by this feature:
chain-validation
OCSP - Server Certification from Alternate Hierarchy
12.4(6)T
This feature provides users with the flexibility to specify multiple OCSP servers, either per client certificate or per group of client certificates, and provides the capability for OCSP server validation based on external CA certificates or self-signed certificates.
The following sections provide information about this feature:
•
The following command was introduced by this feature: match certificate override ocsp
Optional OCSP Nonce
12.2(33)SR
12.4(4)T
This feature provides users with the ability to configure the sending of a nonce, or unique identifier for an OCSP request, during OCSP communications.
The following sections provide information about this feature:
•
•
Certificate Security Attribute-Based Access Control
12.2(15)T
1Under the IPsec protocol, CA interoperability permits Cisco IOS devices and a CA to communicate so that the Cisco IOS device can obtain and use digital certificates from the CA. Certificates contain several fields that are used to determine whether a device or user is authorized to perform a specified action. This feature adds fields to the certificate that allow specifying an ACL, creating a certificate-based ACL.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: crypto pki certificate map, crypto pki trustpoint, match certificate
Online Certificate Status Protocol (OCSP)
12.3(2)T
This feature allows users to enable OCSP instead of CRLs to check certificate status. Unlike CRLs, which provide only periodic certificate status, OCSP can provide timely information regarding the status of a certificate.
The following sections provide information about this feature:
•
•
The following commands were introduced by this feature: ocsp url, revocation-check
PKI AAA Authorization Using the Entire Subject Name
12.3(11)T
This feature provides users with the ability to query the AAA server using the entire subject name from the certificate as a unique AAA username.
The following sections provide information about this feature:
•
•
The following command was modified by this feature: authorization username
PKI Integration with AAA Server
12.3(1)
This feature provides additional scalability for authorization by generating a AAA username from the certificate presented by the peer. A AAA server is queried to determine whether the certificate is authorized for use by the internal component. The authorization is indicated by a component-specified label that must be present in the AV pair for the user.
The following sections provide information about this feature:
•
•
The following commands were introduced by this feature: authorization list, authorization username
PKI: Query Multiple Servers During Certificate Revocation Check
12.3(7)T
This feature introduces the ability for Cisco IOS software to make multiple attempts to retrieve the CRL, allowing operations to continue when a particular server is not available. In addition, the ability to override the CDPs in a certificate with a manually configured CDP has been introduced. Manually overriding the CDPs in a certificate can be advantageous when a particular server is unavailable for an extended period of time. The certificate's CDPs can be replaced with a URL or directory specification without reissuing all of the certificates that contain the original CDP.
The following sections provide information about this feature:
•
•
The following command was introduced by this feature: match certificate override cdp
Using Certificate ACLs to Ignore Revocation Check and Expired Certificates
12.3(4)T
This feature allows a certificate that meets specified criteria to be accepted regardless of the validity period of the certificate, or if the certificate meets the specified criteria, revocation checking does not have to be performed. Certificate ACLs are used to specify the criteria that the certificate must meet to be accepted or to avoid revocation checking. In addition, if AAA communication is protected by a certificate, this feature provides for the AAA checking of the certificate to be ignored.
The following sections provide information about this feature:
•
•
The following command was modified by this feature: match certificate
Query Mode Definition Per Trustpoint
Cisco IOS XE Release 2.1
This feature was introduced on the Cisco ASR 1000 series routers.
PKI High Availability
15.0(1)M
The following commands were introduced or modified: crypto pki server, crypto pki server start, crypto pki server stop, crypto pki trustpoint, crypto key generate rsa, crypto key import pem,crypto key move rsa, show crypto key mypubkey rsa.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2005-2011 Cisco Systems, Inc. All rights reserved.
