- Index
- Preface
- Using Cisco IOS Software
- SIP, SSC, and SPA Product Overview
-
- Overview of the IPsec VPN SPA
- Configuring VPNs in Crypto-Connect Mode
- Configuring VPNs in VRF Mode
- Configuring IPsec VPN Fragmentation and MTU
- Configuring IKE Features Using the IPsec VPN SPA
- Configuring Enhanced IPsec Features Using the IPsec VPN SPA
- Configuring PKI Using the IPsec VPN SPA
- Configuring Advanced VPNs Using the IPsec VPN SPA
- Configuring Duplicate Hardware and IPsec Failover Using the IPsec VPN SPA
- Configuring Monitoring and Accounting for the IPsec VPN SPA
- Troubleshooting the IPsec VPN SPA
- Glossary
- Overview of PKI
- Configuring Multiple RSA Key Pairs
- Configuring Protected Private Key Storage
- Configuring a Trustpoint CA
- Configuring Query Mode Definition Per Trustpoint
- Configuring a Local Certificate Storage Location
- Configuring Direct HTTP Enroll with CA Servers (Reenroll Using Existing Certificates)
- Direct HTTP Enroll with CA Servers Configuration Guidelines and Restrictions
- Configuring an Enrollment Profile for a Client Switch
- Configuring an Enrollment Profile for a Client Switch Enrolled with a Third-Party Vendor CA
- Configuring the CA to Accept Enrollment Requests from Clients of a Third-Party Vendor CA
- Configuring Manual Certificate Enrollment (TFTP and Cut-and-Paste)
- Configuring Certificate Autoenrollment
- Configuring Key Rollover for Certificate Renewal
- Configuring PKI: Query Multiple Servers During Certificate Revocation Check
- Configuring the Online Certificate Status Protocol
- Configuring Certificate Security Attribute-Based Access Control
- Configuring PKI AAA Authorization Using the Entire Subject Name
- Configuring Source Interface Selection for Outgoing Traffic with Certificate Authority
- Configuring Persistent Self-Signed Certificates
- Configuration Examples
- Multiple RSA Key Pairs Configuration Example
- Protected Private Key Storage Configuration Examples
- Trustpoint CA Configuration Example
- Query Mode Definition Per Trustpoint Configuration Example
- Local Certificate Storage Location Configuration Example
- Direct HTTP Enrollment with CA Servers Configuration Examples
- Manual Certificate Enrollment Configuration Examples
- Certificate Autoenrollment Configuration Example
- Key Rollover for Certificate Renewal Configuration Examples
- PKI: Query Multiple Servers During Certificate Revocation Check (CDP Override) Configuration Example
- Online Certificate Status Protocol Configuration Examples
- Certificate Security Attribute-Based Access Control Configuration Example
- PKI AAA Authorization Using the Entire Subject Name Configuration Example
- Source Interface Selection for Outgoing Traffic with Certificate Authority Configuration Example
- Persistent Self-Signed Certificates Configuration Examples
Configuring PKI Using the IPsec VPN SPA
This chapter provides information about configuring PKI-related features using the IPsec VPN SPA on the Catalyst 6500 Series switch. It includes the following sections:
•Configuring Multiple RSA Key Pairs
•Configuring Protected Private Key Storage
•Configuring Query Mode Definition Per Trustpoint
•Configuring a Local Certificate Storage Location
•Configuring Direct HTTP Enroll with CA Servers (Reenroll Using Existing Certificates)
•Configuring Manual Certificate Enrollment (TFTP and Cut-and-Paste)
•Configuring Certificate Autoenrollment
•Configuring Key Rollover for Certificate Renewal
•Configuring PKI: Query Multiple Servers During Certificate Revocation Check
•Configuring the Online Certificate Status Protocol
•Configuring Certificate Security Attribute-Based Access Control
•Configuring PKI AAA Authorization Using the Entire Subject Name
•Configuring Source Interface Selection for Outgoing Traffic with Certificate Authority
•Configuring Persistent Self-Signed Certificates

Note The procedures in this chapter assume you have some familiarity with PKI configuration concepts. For detailed information about PKI configuration concepts and IPsec cryptographic operations and policies, refer to the following Cisco IOS documentation:
Cisco IOS Security Configuration Guide, Release 12.2, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/fsecur_c.html
Cisco IOS Security Command Reference, Release 12.2, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/fsecur_r.html

Note For information about managing your system images and configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2 and Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 publications.
For additional information about the commands used in this chapter, see the the Catalyst 6500 Series Cisco IOS Command Reference, Release 12.2SX and the related Cisco IOS Release 12.2 software configuration guide and master index publications. For more information about accessing these publications, see the "Related Documentation" section on page xlv.

Tip To ensure a successful configuration of your VPN using the IPsec VPN SPA, read all of the configuration summaries and guidelines before you perform any configuration tasks.
Overview of PKI
Cisco IOS public key infrastructure (PKI) provides certificate management to support security protocols such as IP Security (IPsec), secure shell (SSH), and secure socket layer (SSL).
A PKI is composed of the following entities:
•Peers communicating on a secure network
•At least one certificate authority (CA) that grants and maintains certificates
•Digital certificates, which contain information such as the certificate validity period, peer identity information, encryption keys that are used for secure communications, and the signature of the issuing CA
•An optional registration authority (RA) to offload the CA by processing enrollment requests
•A distribution mechanism (such as Lightweight Directory Access Protocol (LDAP) or HTTP) for certificate revocation lists (CRLs)
PKI provides customers with a scalable, secure mechanism for distributing, managing, and revoking encryption and identity information in a secured data network. Every entity (a person or a device) participating in the secured communications is enrolled in the PKI , a process where the entity generates a Rivest, Shamir, and Adelman (RSA) key pair (one private key and one public key) and has their identity validated by a trusted entity (also known as a CA or trustpoint).
After each entity enrolls in a PKI, every peer (also known as an end host) in a PKI is granted a digital certificate that has been issued by a CA. When peers must negotiate a secured communication session, they exchange digital certificates. Based on the information in the certificate, a peer can validate the identity of another peer and establish an encrypted session with the public keys contained in the certificate.
Configuring PKI involves the following tasks:
•Deploying Rivest, Shamir, and Adelman (RSA) keys within a public key infrastructure (PKI). An RSA key pair (a public and a private key) is required before you can obtain a certificate for your router; that is, the end host must generate a pair of RSA keys and exchange the public key with the certificate authority (CA) to obtain a certificate and enroll in a PKI.
•Configuring authorization and revocation of certificates within a PKI. After a certificate is validated as a properly signed certificate, it is authorized using methods such as certificate maps, PKI-AAA, or a certificate-based access control list (ACL). The revocation status is checked by the issuing certificate authority (CA) to ensure that the certificate has not been revoked.
•Configuring certificate enrollment, which is the process of obtaining a certificate from a certificate authority (CA). Certificate enrollment occurs between the end host requesting the certificate and the CA. Each peer that participates in the public key infrastructure (PKI) must enroll with a CA. Various methods are available for certificate enrollment.
•Storing public key infrastructure (PKI) credentials, such as Rivest, Shamir, and Adelman (RSA) keys and certificates. These credentials can be stored in the default location on the router, which is NVRAM, or other locations.
Configuring Multiple RSA Key Pairs
The multiple RSA key pair support feature allows you to configure a Catalyst 6500 Series switch to have multiple Rivest, Shamir, and Adelman (RSA) key pairs. The Cisco IOS software can maintain a different key pair for each identity certificate.
Before this feature, Cisco IOS public key infrastructure (PKI) configurations allowed either one general-purpose key pair or a set of special-purpose key pairs (an encryption and a signing key pair). The scenarios in which the key pairs were deployed often required configurations that required the switch to enroll with multiple certificate servers because each server has an independent policy and may also have different requirements regarding general-purpose versus special-purpose certificates or key length. With this feature, a user can configure different key pairs for each certification authority (CA) with which the switch enrolls and can match policy requirements for each CA without compromising the requirements specified by the other CAs, such as key length, key lifetime, and general-purpose versus special-usage keys.
Multiple RSA Key Pairs Configuration Guidelines and Restrictions
When configuring multiple RSA key pair support, follow these guidelines and restrictions:
•We recommend that Secure Socket Layer (SSL) or other PKI clients do not attempt to enroll with the same CA multiple times.
•Internet Key Exchange (IKE) will not work for any identity that is configured to use a named key pair. If an IKE peer requests a certificate from a PKI trustpoint that is using multiple key support, the initial portion of the exchange will work, that is, the correct certificate will be sent in the certificate response; however, the named keypair will not be used and the IKE negotiation will fail.
•Whenever you regenerate a key pair, you must always reenroll the certificate identities with that key pair.
To configure an RSA key pair, perform this task beginning in global configuration mode:
Removing RSA Key Pair Settings
To delete a specified RSA key pair or all RSA key pairs that have been generated by your switch, enter the crypto key zeroize rsa command in global configuration mode as follows:
Router(config)# crypto key zeroize rsa [key-pair-label]
key-pair-label specifies the name of the key pair to be deleted. If the key-pair-label argument is used, you will delete only the specified RSA key pair. If no argument is used, you will delete all the RSA key pairs from your switch.
Verifying RSA Key Information
To verify RSA key information, use at least one of the privileged EXEC commands used in the examples.
To display your switch's RSA public keys, use the show crypto key mypubkey rsa command:
Router# show crypto key mypubkey rsa
% Key pair was generated at: 06:07:50 UTC Jan 13 1996
Key name: myswitch.example.com
Usage: Encryption Key
Key Data:
00302017 4A7D385B 1234EF29 335FC973 2DD50A37 C4F4B0FD 9DADE748 429618D5
18242BA3 2EDFBDD3 4296142A DDF7D3D8 08407685 2F2190A0 0B43F1BD 9A8A26DB
07953829 791FCDE9 A98420F0 6A82045B 90288A26 DBC64468 7789F76E EE21
To display a list of all the RSA public keys stored on your switch (including the public keys of peers that have sent your switch their certificates during peer authentication for IPsec), or to display details of a particular RSA public key stored on your switch, use the show crypto key pubkey-chain rsa command:
Router# show crypto key pubkey-chain rsa
Codes: M - Manually Configured, C - Extracted from certificate
Code Usage IP-address Name
M Signature 10.0.0.l myrouter.example.com
M Encryption 10.0.0.1 myrouter.example.com
C Signature 172.16.0.1 routerA.example.com
C Encryption 172.16.0.1 routerA.example.com
C General 192.168.10.3 routerB.domain1.com
For complete configuration information for Multiple RSA Key Pair Support, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftmltkey.html
For an RSA key pair configuration example, see the "Multiple RSA Key Pairs Configuration Example" section.
Configuring Protected Private Key Storage
The protected private key storage feature allows a user to encrypt and lock the RSA private keys that are used on a Catalyst 6500 Series switch, which prevents unauthorized use of the private keys.
Protected Private Key Storage Configuration Guidelines and Restrictions
When configuring protected private key storage, follow these guidelines and restrictions:
•An encrypted key is not effective after the switch boots up until you manually unlock the key (using the crypto key unlock rsa command). Depending on which key pairs are encrypted, this functionality may adversely affect applications such as IP Security (IPsec), Secure Shell (SSH) and Secure Socket Layer (SSL); that is, management of the switch over a secure channel may not be possible until the necessary key pair is unlocked.
•If a passphrase is lost, you must regenerate the key, enroll with the CA server again, and obtain a new certificate. A lost passphrase cannot be recovered.
•If you want to change a passphrase, you must decrypt the key with the current passphrase using the crypto key decrypt rsa command and encrypt the key once more to specify the new passphrase.
Configuring Private Keys
To encrypt, decrypt, lock, and unlock private keys, perform this task beginning in global configuration mode:
Verifying the Protected and Locked Private Keys
To verify that the key is protected (encrypted) and locked, enter the show crypto key mypubkey rsa command:
Router# show crypto key mypubkey rsa
% Key pair was generated at:20:29:41 GMT Jun 20 2003
Key name:pki1-72a.cisco.com
Usage:General Purpose Key
*** The key is protected and LOCKED. ***
Key is exportable.
Key Data:
305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00D7808D C5FF14AC
0D2B55AC 5D199F2F 7CB4B355 C555E07B 6D0DECBE 4519B1F0 75B12D6F 902D6E9F
B6FDAD8D 654EF851 5701D5D7 EDA047ED 9A2A619D 5639DF18 EB020301 0001
For complete configuration information for protected private key storage, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_ppkey.html
For protected private key configuration examples, see the "Protected Private Key Storage Configuration Examples" section.
Configuring a Trustpoint CA
The crypto pki trustpoint command allows you to declare the certificate authority (CA) that your switch should use and to specify characteristics for the CA.
The crypto pki trustpoint command combines and replaces the functionality of the existing crypto ca identity command and the crypto ca trusted-root command. Although both of these existing commands allow you to declare the certification authority (CA) that your switch should use, only the crypto ca identity command supports enrollment (the requesting of a switch certificate from a CA).
Trustpoint CA Configuration Guidelines and Restrictions
When configuring a trustpoint CA, follow these guidelines and restrictions:
•After the trustpoint CA has been configured, you can obtain the certificate of the CA by using the crypto pki authenticate command or you can specify that certificates should not be stored locally but retrieved from a CA trustpoint by using the crypto pki certificate query command.
•Normally, certain certificates are stored locally in the switch's NVRAM, and each certificate uses a moderate amount of memory. To save NVRAM space, you can use the crypto pki certificate query command to put the switch into query mode, preventing certificates from being stored locally; instead, they are retrieved from a specified CA trustpoint when needed. This will save NVRAM space but could result in a slight performance impact.
To declare the CA that your switch should use and specify characteristics for the trustpoint CA, perform this task beginning in global configuration mode:
Verifying a Trustpoint CA
To verify information about your certificate, the certificate of the CA, and registration authority (RA) certificates, enter the show crypto pki certificates command:
Router# show crypto pki certificates
CA Certificate
Status: Available
Certificate Serial Number: 3051DF7123BEE31B8341DFE4B3A338E5F
Key Usage: Not Set
RA Signature Certificate
Status: Available
Certificate Serial Number: 34BCF8A0
Key Usage: Signature
RA KeyEncipher Certificate
Status: Available
Certificate Serial Number: 34BCF89F
Key Usage: Encryption
To display the trustpoints that are configured in the switch, enter the show crypto pki trustpoints command:
Router# show crypto pki trustpoints
Trustpoint bo:
Subject Name:
CN = bomborra Certificate Manager
O = cisco.com
C = US
Serial Number:01
Certificate configured.
CEP URL:http://bomborra
CRL query url:ldap://bomborra
For complete configuration information for the trustpoint CA, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/fttrust.html
For a trustpoint CA configuration example, see the "Trustpoint CA Configuration Example" section.
Configuring Query Mode Definition Per Trustpoint
Certificates contain public key information and are signed by certificate authority (CA) as proof of identity. Normally, all certificates are stored locally in the switch's NVRAM, and each certificate uses a moderate amount of memory. The query mode definition per trustpoint feature allows you to define a query for a specific trustpoint so that the certificates associated with that specific trustpoint can be stored on a remote server.
This feature is especially useful for environments where multiple trustpoints are configured on a switch because it allows you more control over use of the trustpoint. Query mode can be activated on specific trustpoints rather than on all of the trustpoints on a switch.
Query Mode Definition Per Trustpoint Configuration Guidelines and Restrictions
When configuring query mode definition per trustpoint, follow these guidelines and restrictions:
•Normally, certain certificates are stored locally in the switch's NVRAM, and each certificate uses a moderate amount of memory. To save NVRAM space, you can use the query certificate command to prevent certificates from being stored locally; instead, they are retrieved from a remote server, such as a CA or LDAP server, during startup. This will save NVRAM space but could result in a slight performance impact.
•Certificates associated with a specified trustpoint will not be written into NVRAM and the certificate query will be attempted during the next reload of the switch.
•When the global crypto pki certificate query command is used, the query certificate will be added to all trustpoints on the switch. When the no crypto pki certificate query command is used, any previous query certificate configuration will be removed from all trustpoints and any query in progress will be halted and the feature disabled.
To configure a trustpoint CA and initiate query mode for the trustpoint, perform this task beginning in global configuration mode:
Verifying Query Mode Definition Per Trustpoint CA
For query mode to operate correctly during the next reload, the certificates must be associated with the trustpoint. Use the show crypto pki certificates command to verify that each of the trustpoints has the needed certificates before storing the configuration and reloading the switch:
Router# show crypto pki certificates
Trustpoint yni:
Issuing CA certificate pending:
Subject Name:
cn=nsca-r1 Cert Manager,ou=pki,o=cisco.com,c=US
Fingerprint: C21514AC 12815946 09F635ED FBB6CF31
Router certificate pending:
Subject Name:
hostname=trance.cisco.com,o=cisco.com
Next query attempt:
52 seconds
For complete configuration information for Query Mode Definition Per Trustpoint, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_qerym.html
For a query mode definition per trustpoint configuration example, see the "Query Mode Definition Per Trustpoint Configuration Example" section.
Configuring a Local Certificate Storage Location
The Local Certificate Storage Location feature enables you to store public key infrastructure (PKI) credentials, such as Rivest, Shamir, and Adelman (RSA) keys and certificates in a specific location. An example of a certificate storage location includes NVRAM, which is the default location, and other local storage locations as supported by your platform, such as flash.

Note The Local Certificate Storage Location feature is supported in Cisco IOS Release 12.2(33)SXH and later releases.
Local Certificate Storage Location Configuration Guidelines and Restrictions
Follow these guidelines and restrictions when configuring a local certificate storage location:
•Before you can specify the local certificate storage location, your system should meet the following requirements:
–A Cisco IOS Release 12.4(2)T PKI-enabled image or a later image
–A platform that supports storing PKI credentials as separate files
–A configuration that contains at least one certificate
–An accessible local file system
•When storing certificates to a local storage location, the following restrictions are applicable:
–Only local file systems may be used. An error message will be displayed if a remote file system is selected, and the command will not take effect.
–A subdirectory may be specified if supported by the local file system. NVRAM does not support subdirectories.
–Certificates are stored to NVRAM by default, however, some routers do not have the required amount of NVRAM to successfully store certificates. Introduced in Cisco IOS Release 12.4(2)T is the ability to specify where certificates are stored on a local file system.
–During run time, you can specify what active local storage device you would like to use to store certificates.
Specifying a Local Storage Location for Certificates
To specify the local storage location for certificates, perform the following steps beginning in global configuration mode:
Verifying the Local Certificate Storage Location Configuration
To verify a local certificate storage location configuration, enter the show crypto pki certificates storage command.
The show crypto pki certificates storage command displays the current setting for the PKI certificate storage location.
The following example shows that certificates are stored in the certs subdirectory of disk0:
Router# show crypto pki certificates storage
Certificates will be stored in disk0:/certs/
For complete configuration information for local certificate storage location, refer to the Cisco IOS Security Configuration Guide or the following URL:
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t2/st_pkist.html
For local certificate storage configuration examples, see the "Local Certificate Storage Location Configuration Example" section.
Configuring Direct HTTP Enroll with CA Servers (Reenroll Using Existing Certificates)
The direct HTTP enroll with CA servers feature allows users to bypass the registration authority (RA) when enrolling with a certification authority (CA) by configuring an enrollment profile. HTTP enrollment requests can be sent directly to the CA server.
The reenroll using existing certificates functionality allows a switch that is enrolled with a third-party vendor CA to use its existing certificate to enroll with the Cisco IOS certificate server so the enrollment request is automatically granted.
Direct HTTP Enroll with CA Servers Configuration Guidelines and Restrictions
When configuring direct HTTP enroll with CA servers, follow these guidelines and restrictions:
•The CA certificate and switch certificates must be returned in the privacy enhanced mail (PEM) format.
•If an enrollment profile is specified, an enrollment URL can not be specified in the trustpoint configuration.
•Because there is no standard for the HTTP commands used by various CAs, the user is required to enter the command that is appropriate to the CA that is being used.
•The newly created trustpoint can only be used one time (which occurs when the switch is enrolled with the Cisco IOS CA). After the initial enrollment is successfully completed, the credential information will be deleted from the enrollment profile.
•The Cisco IOS certificate server will automatically grant only the requests from clients who were already enrolled with the non-Cisco IOS CA. All other requests must be manually granted unless the server is set to be in auto grant mode (using the grant automatic command).
•To configure direct HTTP enroll with CA servers, you must perform the following steps:
–Either configure a certificate enrollment profile for the client switch (see the "Configuring an Enrollment Profile for a Client Switch" section) or configure an enrollment profile for a client switch that is already enrolled with a third-party vendor (see the "Configuring an Enrollment Profile for a Client Switch Enrolled with a Third-Party Vendor CA" section).
–Configure the CA certificate server to accept enrollment requests only from clients who are already enrolled with the third-party vendor CA trustpoint (see the "Configuring the CA to Accept Enrollment Requests from Clients of a Third-Party Vendor CA" section).
Configuring an Enrollment Profile for a Client Switch
To configure a certificate enrollment profile, perform this task beginning in global configuration mode:
In configuring the direct HTTP enrollment profile, you can use the parameter command within an enrollment profile to provide predefined or console-input parameters to the authentication command command or the enrollment command command.
When you enter the parameter number command, a macroinstruction (macro) is created and named $Pnumber (for example, $P1). If the value keyword is specified, the value argument is assigned to the macro. If the prompt keyword is specified, when the switch executes the authentication command command or the enrollment command command, the console will display the string argument as a prompt for user input. You can then enter a value to be assigned to the macro.
In addition to user-defined macros, three predefined macros are available:
•$REQ—The Certification Request Standard (PKCS #10) message to request certification of a key
•$FQDN—The FQDN of the switch
•$HOST—The hostname of the switch
This example shows how to use one predefined and three user-defined macros:
Router(config)# crypto ca profile enrollment E
Router(ca-profile-enroll)# authentication url http://ca-server.example.com
Router(ca-profile-enroll)# authentication command GET $P1
Router(ca-profile-enroll)# enrollment url
Router(ca-profile-enroll)# enrollment command ^C
POST action=getServerCert
&pkcs10Request=$REQ
&reference_number=$P2
&authcode=P3
&retrievedAs=rawDER
^C
Router(ca-profile-enroll)# parameter 1 value cacert.crt
Router(ca-profile-enroll)# parameter 2 prompt Enter the Reference Number:
Router(ca-profile-enroll)# parameter 3 prompt Enter the Auth Code:
Before the HTTP authentication and enrollment commands are posted by the switch to the CA, the console will prompt for any required user input, and macro values will be substituted for the macro names in the posted commands.
For an example of how to configure an enrollment profile for direct HTTP enrollment with a CA server, see the "Enrollment Profile for a Client Switch Configuration Example" section.
Configuring an Enrollment Profile for a Client Switch Enrolled with a Third-Party Vendor CA
When a client switch is already enrolled with a third-party vendor CA, but you want to reenroll that switch with a Cisco IOS certificate server, perform the following procedures. Note that some prerequisite steps are required before beginning the configuration.
Prerequisites
Before configuring a certificate enrollment profile for the client switch enrolled with a third-party vendor, you should have already performed the following tasks at the client switch:
•Defined a trustpoint that points to a third-party vendor CA.
•Authenticated and enrolled the client switch with the third-party vendor CA.
To configure a certificate enrollment profile for a client switch that is already enrolled with a third-party vendor CA so that the switch can reenroll with a Cisco IOS certificate server, perform this task beginning in global configuration mode:
For an example of how to configure a certificate enrollment profile for a client switch that is already enrolled with a third-party vendor CA, see the "Enrollment Profile for a Client Switch Already Enrolled with a Third-Party Vendor CA Example" section.
Configuring the CA to Accept Enrollment Requests from Clients of a Third-Party Vendor CA
To configure the CA certificate server to accept enrollment requests only from clients who are already enrolled with the third-party vendor CA trustpoint, perform this task beginning in global configuration mode:
For complete configuration information for direct HTTP enroll with CA servers, including the "reenroll using existing certificates" functionality, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gthttpca.html
For direct HTTP enroll with CA servers configuration examples, see the "Direct HTTP Enrollment with CA Servers Configuration Examples" section.
Configuring Manual Certificate Enrollment (TFTP and Cut-and-Paste)
The manual certificate enrollment (TFTP and cut-and-paste) feature allows users to generate a certificate request and accept certification authority (CA) certificates as well as the switch's certificates; these tasks are accomplished by a TFTP server or manual cut-and-paste operations. You might want to utilize TFTP or manual cut-and-paste enrollment in the following situations:
•The CA does not support Simple Certificate Enrollment Protocol (SCEP) (which is the most commonly used method for sending and receiving requests and certificates).
•A network connection between the switch and CA is not possible (which is how a switch running Cisco IOS software obtains its certificate).
Manual Certificate Enrollment (TFTP and Cut-and-Paste) Configuration Guidelines and Restrictions
When configuring nanualcertificate enrollment (TFTP and cut-and-paste), follow these guidelines and restrictions:
•You can switch between TFTP and cut-and-paste; for example, you can paste the CA certificate using the enrollment terminal command, then enter no enrollment terminal and enrollment url tftp://certserver/file_specification to switch to TFTP to send or receive requests and switch certificates. However, Cisco does not recommend switching URLs if SCEP is used; that is, if the enrollment URL is http://, do not change the enrollment URL between fetching the CA certificate and enrolling the certificate.
Configuring Manual Enrollment Using TFTP
Before configuring manual enrollment using TFTP, you must meet the following prerequisites:
•You must know the correct URL to use if you are configuring certificate enrollment using TFTP.
•The switch must be able to write a file to the TFTP server for the crypto pki enroll command.
•Some TFTP servers require that the file exist on the server before it may be written.
•Most TFTP servers require that the file be writeable by anyone. This requirement may pose a risk because any switch or other device may write or overwrite the certificate request; thus, the switch will not be able to use the certificate once it is granted by the CA because the request was modified.
To declare the trustpoint CA that your switch should use and configure that trustpoint CA for manual enrollment using TFTP, perform this task beginning in global configuration mode:
Configuring Certificate Enrollment Using Cut-and-Paste
To declare the trustpoint CA that your switch should use and configure that trustpoint CA for manual enrollment using cut-and-paste, perform this task:
Verifying the Manual Certificate Enrollment Configuration
To verify information about your certificate, the certificate of the CA, and RA certificates, enter the show crypto pki certificates command:
Router# show crypto pki certificates
Certificate
Status:Available
Certificate Serial Number:14DECE05000000000C48
Certificate Usage:Encryption
Issuer:
CN = msca-root
O = Cisco Systems
C = U
Subject:
Name:Switch.cisco.com
OID.1.2.840.113549.1.9.2 = Switch.cisco.com
CRL Distribution Point:
http://msca-root/CertEnroll/msca-root.crl
Validity Date:
start date:18:16:45 PDT Jun 7 2008
end date:18:26:45 PDT Jun 7 2009
renew date:16:00:00 PST Dec 31 1969
Associated Trustpoints:MS
Certificate
Status:Available
Certificate Serial Number:14DEC2E9000000000C47
Certificate Usage:Signature
Issuer:
CN = msca-root
O = Cisco Systems
C = US
Subject:
Name:Switch.cisco.com
OID.1.2.840.113549.1.9.2 = Switch.cisco.com
CRL Distribution Point:
http://msca-root/CertEnroll/msca-root.crl
Validity Date:
start date:18:16:42 PDT Jun 7 2008
end date:18:26:42 PDT Jun 7 2009
renew date:16:00:00 PST Dec 31 1969
Associated Trustpoints:MS
CA Certificate
Status:Available
Certificate Serial Number:3AC0A65E9547C2874AAF2468A942D5EE
Certificate Usage:Signature
Issuer:
CN = msca-root
O = Cisco Systems
C = US
Subject:
CN = msca-root
O = Cisco Systems
C = US
CRL Distribution Point:
http://msca-root/CertEnroll/msca-root.crl
Validity Date:
start date:16:46:01 PST Feb 13 2008
end date:16:54:48 PST Feb 13 2013
Associated Trustpoints:MS
To display the trustpoints that are configured in the switch, enter the show crypto pki trustpoints command:
Router# show crypto pki trustpoints
Trustpoint bo:
Subject Name:
CN = ACSWireless Certificate Manager
O = cisco.com
C = US
Serial Number:01
Certificate configured.
CEP URL:http://ACSWireless
CRL query url:ldap://ACSWireless
For complete configuration information for manual certificate enrollment (TFTP and cut-and-paste), refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftmancrt.html
For manual certificate enrollment configuration examples, see the "Manual Certificate Enrollment Configuration Examples" section.
Configuring Certificate Autoenrollment
The certificate autoenrollment feature allows you to configure your switch to automatically request a certificate from the certification authority (CA) that is using the parameters in the configuration. Thus, operator intervention is no longer required at the time the enrollment request is sent to the CA server.
Automatic enrollment will be performed on startup for any trustpoint CA that is configured and does not have a valid certificate. When the certificate expires that is issued by a trustpoint CA that has been configured for autoenrollment, a new certificate is requested. Although this feature does not provide seamless certificate renewal, it does provide unattended recovery from expiration.
Before the certificate autoenrollment feature, certificate enrollment required complicated, interactive commands that had to be executed on every switch. This feature allows you to preload all of the necessary information into the configuration and cause each switch to obtain certificates automatically when it is booted. Autoenrollment also checks for expired switch certificates.

Note Before submitting an automatic enrollment request, all necessary enrollment information must be configured.
To configure autoenrollment with a CA on startup, perform this task beginning in global configuration mode:
Preloading Root CAs
After enabling automatic enrollment, you must authenticate the CA to establish a chain of trust. This can be done by implementing one of the following methods:
•Adding the Certificate of the CA
Obtaining the CA Certificate
To obtain the certificate of the CA, enter the crypto pki authenticate command in global configuration mode.
Router(config)# crypto pki authenticate name
name specifies the name of the CA.
Adding the Certificate of the CA
To add the certificate of the CA, perform this task beginning in global configuration mode:
Verifying CA Information
To display information about your certificates, the certificates of the CA, and registration authority (RA) certificates, enter the show crypto pki certificates command:
Router# show crypto pki certificates
Certificate
Subject Name
Name: myrouter.example.com
IP Address: 10.0.0.1
Status: Available
Certificate Serial Number: 428125BDA34196003F6C78316CD8FA95
Key Usage: Signature
Certificate
Subject Name
Name: myswitch.example.com
IP Address: 10.0.0.1
Status: Available
Certificate Serial Number: AB352356AFCD0395E333CCFD7CD33897
Key Usage: Encryption
CA Certificate
Status: Available
Certificate Serial Number: 3051DF7123BEE31B8341DFE4B3A338E5F
Key Usage: Not Set
To display the trustpoints configured in the switch, enter the show crypto pki trustpoints command:
Router# show crypto pki trustpoints
Trustpoint bo:
Subject Name:
CN = bomborra Certificate Manager
O = cisco.com
C = US
Serial Number:01
Certificate configured.
CEP URL:http://bomborra
CRL query url:ldap://bomborra
For complete configuration information for Certificate Autoenrollment, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftautoen.html
For a certificate autoenrollment configuration example, see the "Certificate Autoenrollment Configuration Example" section.
Configuring Key Rollover for Certificate Renewal
Automatic certificate enrollment was introduced to allow the switch to automatically request a certificate from the certification authority (CA) server. By default, the automatic enrollment feature requests a new certificate when the old certificate expires. Connectivity can be lost while the request is being serviced because the existing certificate and key pairs are deleted immediately after the new key is generated. The new key does not have a certificate to match it until the process is complete, and incoming Internet Key Exchange (IKE) connections cannot be established until the new certificate is issued. The key rollover for certificate renewal feature allows the certificate renewal request to be made before the certificate expires and retains the old key and certificate until the new certificate is available.
Key rollover can also be used with a manual certificate enrollment request. Using the same method as key rollover with certificate autoenrollment, a new key pair is created with a temporary name, and the old certificate and key pair are retained until a new certificate is received from the CA. When the new certificate is received, the old certificate and key pair are discarded and the new key pair is renamed with the name of the original key pair. Do not regenerate the keys manually; key rollover will occur when you enter the crypto pki enroll command.
Key Rollover for Certificate Renewal Configuration Guidelines and Restrictions
When configuring key rollover for certificate renewal, follow these guidelines and restrictions:
•Trustpoints configured to generate a new key pair using the regenerate command or the regenerate keyword of the auto-enroll command must not share key pairs with other trustpoints. To give each trustpoint its own key pair, use the rsakeypair command in ca-trustpoint configuration mode. Sharing key pairs among regenerating trustpoints is not supported and will cause loss of service on some of the trustpoints because of key and certificate mismatch.
Configuring Automatic Certificate Enrollment with Key Rollover
To configure key rollover with automatic certificate enrollment, perform this task beginning in global configuration mode:
Configuring Manual Certificate Enrollment with Key Rollover

Note Do not regenerate the keys manually using the crypto key generate command; key rollover will occur when the crypto pki enroll command is entered.
To configure key rollover with manual certificate enrollment, perform this task beginning in global configuration mode:
For complete configuration information for key rollover for certificate renewal, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtkyroll.html
For key rollover configuration examples, see the "Key Rollover for Certificate Renewal Configuration Examples" section.
Configuring PKI: Query Multiple Servers During Certificate Revocation Check
Before an X.509 certificate presented by a peer is validated, the certificate revocation list (CRL) is checked to make sure that the certificate has not been revoked by the issuing certification authority (CA). The certificate usually contains a certificate distribution point (CDP) in the form of a URL. Cisco IOS software uses the CDP to locate and retrieve the CRL.
Previous versions of Cisco IOS software make only one attempt to retrieve the CRL, even when the certificate contains more than one CDP. If the CDP server does not respond, the Cisco IOS software reports an error, which may result in the peer's certificate being rejected.
The PKI:query multiple servers during certificate revocation check feature provides the ability for Cisco IOS software to make multiple attempts to retrieve the CRL by trying all of the available CDPs in a certificate. This allows 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 is also provided. 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.
To manually override the existing CDPs for a certificate with a URL or directory specification, perform this task beginning in global configuration mode:
For complete configuration information for the PKI: Query Multiple Servers During Certificate Revocation Check feature, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtcertrc.html
For a query multiple servers configuration example, see the "PKI: Query Multiple Servers During Certificate Revocation Check (CDP Override) Configuration Example" section.
Configuring the Online Certificate Status Protocol
The Online Certificate Status Protocol (OCSP) feature allows users to enable OCSP instead of certificate revocation lists (CRLs) to check certificate status. Unlike CRLs, which provide only periodic certificate status, OCSP can provide timely information regarding the status of a certificate.
OCSP Configuration Guidelines and Restrictions
When configuring OCSP, follow these guidelines and restrictions:
•OCSP transports messages over HTTP, so there may be a time delay when you access the OCSP server. If the OCSP server is unavailable, certificate verification will fail.
•The increased certificate size may cause a problem for low-end switches when certificates are stored on NVRAM. Before you add the Authority Info Access (AIA) extension to a certificate, make sure that the increased size will not cause deployment problems.
•An OCSP server usually operates in either push or poll mode. You can configure a CA server to push revocation information to an OCSP server or configure an OCSP server to periodically download (poll) a CRL from the CA server. To ensure that timely certificate revocation status is obtained, you should carefully consider the push and poll interval.
•When configuring an OCSP server to return the revocation status for a CA server, the OCSP server must be configured with an OCSP response signing certificate that is issued by that CA server. Ensure that the signing certificate is in the correct format, or the switch will not accept the OCSP response. Refer to your OCSP manual for additional information.
To configure your switch for OCSP to check certificate status, perform this task beginning in global configuration mode:
Verifying the OCSP Configuration
To display information about your certificate and the CA certificate, enter the show crypto pki certificates command:
Router# show crypto pki certificates
Certificate
Status: Available
Version: 3
Certificate Serial Number: 18C1EE03000000004CBD
Certificate Usage: General Purpose
Issuer:
cn=msca-root
ou=pki msca-root
o=cisco
l=santa cruz2
st=CA
c=US
ea=user@example.com
Subject:
Name: myrouter.example.com
hostname=myrouter.example.com
CRL Distribution Points:
http://msca-root/CertEnroll/msca-root.crl
Validity Date:
start date: 19:50:40 GMT Oct 5 2004
end date: 20:00:40 GMT Oct 12 2004
Subject Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (360 bit)
Signature Algorithm: SHA1 with RSA Encryption
Fingerprint MD5: 2B5F53E6 E3E892E6 3A9D3706 01261F10
Fingerprint SHA1: 315D127C 3AD34010 40CE7F3A 988BBDA5 CD528824
X509v3 extensions:
X509v3 Key Usage: A0000000
Digital Signature
Key Encipherment
X509v3 Subject Key ID: D156E92F 46739CBA DFE66D2D 3559483E B41ECCF4
X509v3 Authority Key ID: 37F3CC61 AF5E7C0B 434AB364 CF9FA0C1 B17C50D9
Authority Info Access:
Associated Trustpoints: msca-root
Key Label: myrouter.example.com
CA Certificate
Status: Available
Version: 3
Certificate Serial Number: 1244325DE0369880465F977A18F61CA8
Certificate Usage: Signature
Issuer:
cn=msca-root
ou=pki msca-root
o=cisco
l=santa cruz2
st=CA
c=US
ea=user@example.com
Subject:
cn=msca-root
ou=pki msca-root
o=cisco
l=santa cruz2
st=CA
c=US
ea=user@example.com
CRL Distribution Points:
http://msca-root.example.com/CertEnroll/msca-root.crl
Validity Date:
start date: 22:19:29 GMT Oct 31 2002
end date: 22:27:27 GMT Oct 31 2017
Subject Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Signature Algorithm: SHA1 with RSA Encryption
Fingerprint MD5: 84E470A2 38176CB1 AA0476B9 C0B4F478
Fingerprint SHA1: 0F57170C 654A5D7D 10973553 EFB0F94F 2FAF9837
X509v3 extensions:
X509v3 Key Usage: C6000000
Digital Signature
Non Repudiation
Key Cert Sign
CRL Signature
X509v3 Subject Key ID: 37F3CC61 AF5E7C0B 434AB364 CF9FA0C1 B17C50D9
X509v3 Basic Constraints:
CA: TRUE
Authority Info Access:
Associated Trustpoints: msca-root
To display the trustpoints and configured trustpoint subcommands that are configured in the switch, enter the show crypto pki trustpoints command:
Router# show crypto pki trustpoints
Trustpoint bo:
Subject Name:
CN = bomborra Certificate Manager
O = cisco.com
C = US
Serial Number:01
Certificate configured.
CEP URL:http://bomborra
CRL query url:ldap://bomborra
For complete configuration information for OCSP, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_ocsp.html
For OCSP configuration examples, see the "Online Certificate Status Protocol Configuration Examples" section.
Configuring Certificate Security Attribute-Based Access Control
Under the IPsec protocol, certificate authority (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. The certificate security attribute-based access control feature adds fields to the certificate to create a certificate-based ACL.
Certificate Security Attribute-Based Access Control Configuration Guidelines and Restrictions
When configuring certificate security attribute-based access control, follow these guidelines and restrictions:
•The certificate-based ACL specifies 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 can be specified multiple times within the same ACL.
•More than one ACL can be specified. Each ACL will be processed in turn until a match is found or all of the ACLs have been processed.
•Memory is required to hold the ACLs as they are created and as they are loaded from the configuration file. The amount of memory depends on which fields within the certificate are being checked and how many ACLs have been defined. Certificate-based ACL support requires one or more compare operations when the fields in a certificate are being checked. Only the fields specified by the ACL are checked. The compare operations are a small part of certificate validation and will not have a noticeable effect on switch performance when validating certificates.
To configure Certificate Security Attribute-Based Access Control, perform this task beginning in global configuration mode:
Verifying Certificate-Based ACLs
To verify the certificate-based ACL configuration, enter the show crypto pki certificates command. The following example shows the components of the certificates (CA and switch certificate) installed on the switch when the switch has both authenticated and enrolled with a trustpoint:
Router# show crypto pki certificates
CA Certificate
Status: Available
Certificate Serial Number: 1244325DE0369880465F977A18F61CA8
Certificate Usage: Signature
Issuer:
CN = new-user
OU = pki new-user
O = cisco
L = santa cruz2
ST = CA
C = US
EA = user@cysco.net
Subject:
CN = new-user
OU = pki new-user
O = cisco
L = santa cruz2
ST = CA
C = US
EA = user@cysco.net
CRL Distribution Point:
http://new-user.cysco.net/CertEnroll/new-user.crl
Validity Date:
start date: 14:19:29 PST Oct 31 2002
end date: 14:27:27 PST Oct 31 2017
Associated Trustpoints: MS
Certificate
Status: Available
Certificate Serial Number: 193E28D20000000009F7
Certificate Usage: Signature
Issuer:
CN = new-user
OU = pki new-user
O = cisco
L = santa cruz2
ST = CA
C = US
EA = user@cysco.net
Subject:
Name: User1.Cysco.Net
OID.1.2.840.113549.1.9.2 = User1.Cysco.Net
CRL Distribution Point:
http://new-user.cysco.net/CertEnroll/new-user.crl
Validity Date:
start date: 12:40:14 PST Feb 26 2003
end date: 12:50:14 PST Mar 5 2003
renew date: 16:00:00 PST Dec 31 1969
Associated Trustpoints: MS
For complete configuration information for Certificate Security Attribute-Based Access Control, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftcrtacl.html
For a certificate-based ACL example, see the "Certificate Security Attribute-Based Access Control Configuration Example" section.
Configuring PKI AAA Authorization Using the Entire Subject Name
When using public key infrastructure (PKI) and authentication, authorization, and accounting (AAA) functionality, users sometimes have attribute-value (AV) pairs that are different from those of every other user. As a result, a unique username is required for each user. The PKI AAA authorization using the entire subject name feature provides users with the ability to query the AAA server using the entire subject name from the certificate as a unique AAA username.
PKI AAA Authorization Using the Entire Subject Name Configuration Guidelines and Restrictions
When configuring PKI AAA authorization using the entire subject name, follow these guidelines and restrictions:
•Some AAA servers limit the length of the username (for example, to 64 characters). As a result, the entire certificate subject name cannot be longer than the limitation of the server.
•Some AAA servers limit the available character set that may be used for the username (for example, a space [ ] and an equal sign [=] may not be acceptable). This feature will not work for the AAA server having such a character-set limitation.
•The subject-name command in the trustpoint configuration might not always be the final AAA subject name. If the fully qualified domain name (FQDN), serial number, or IP address of the switch are included in a certificate request, the subject name field of the issued certificate will also have these components. To turn off the components, use the fqdn, serial-number, and ip-address commands with the none keyword.
•Certificate authority (CA) servers sometimes change the requested subject name field when they issue a certificate. For example, CA servers of some vendors switch the relative distinguished names (RDNs) in the requested subject names to the following order: CN, OU, O, L, ST, and C. However, another CA server might append the configured Lightweight Directory Access Protocol (LDAP) directory root (for example, O=cisco.com) to the end of the requested subject name.
•Depending on the tools you choose for displaying a certificate, the printed order of the RDNs in the subject name could be different. Cisco IOS software always displays the least significant RDN first, but other software, such as Open Source Secure Socket Layer (OpenSSL), does the opposite. Therefore, if you are configuring the AAA server with a full DN (subject name) as the corresponding username, ensure that the Cisco IOS software style (that is, with the least-significant RDN first) is used.
To configure the entire certificate subject name for PKI authentication, perform this task beginning in global configuration mode:
For complete configuration information for the PKI AAA authorization using the entire subject name feature, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gt_dnall.html
For a PKI AAA Authorization Using the Entire Subject Name configuration example, see the "PKI AAA Authorization Using the Entire Subject Name Configuration Example" section.
Configuring Source Interface Selection for Outgoing Traffic with Certificate Authority
The source interface selection for outgoing traffic with certificate authority feature allows you to specify that the address of an interface be used as the source address for all outgoing TCP connections associated with that trustpoint when a designated trustpoint has been configured.
To configure the interface that you want to use as the source address for all outgoing TCP connections associated with a trustpoint, perform this task beginning in global configuration mode:
For complete configuration information for source interface selection for outgoing traffic with certificate authority, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_asish.html
For a source interface selection configuration example, see the "Source Interface Selection for Outgoing Traffic with Certificate Authority Configuration Example" section.
Configuring Persistent Self-Signed Certificates
The persistent self-signed certificates feature saves a certificate generated by a Secure HTTP (HTTPS) server for the Secure Sockets Layer (SSL) handshake in a router's startup configuration.

Note The persistent self-signed certificates feature is supported in Cisco IOS Release 12.2(33)SXH and later releases.
Cisco IOS software has an HTTPS server that allows access to web-based management pages using a secure SSL connection. SSL requires the server to have an X.509 certificate that is sent to the client (web browser) during the SSL handshake to establish a secure connection between the server and the client.
The client expects the SSL server's certificate to be verifiable using a certificate the client already possesses.
If Cisco IOS software does not have a certificate that the HTTPS server can use, the server generates a self-signed certificate by calling a public key infrastructure (PKI) application programming interface (API). When the client receives this self-signed certificate and is unable to verify it, intervention is needed. The client asks you if the certificate should be accepted and saved for future use. If you accept the certificate, the SSL handshake continues.
Future SSL handshakes between the same client and the server use the same certificate. However, if the router is reloaded, the self-signed certificate is lost. The HTTPS server must then create a new self-signed certificate. This new self-signed certificate does not match the previous certificate, so you are once again asked to accept it.
Requesting acceptance of the router's certificate each time that the router reloads can be annoying and may present an opportunity for an attacker to substitute an unauthorized certificate during the time that you are being asked to accept the certificate.
The persistent self-signed certificates feature overcomes all these limitations by saving a certificate in the router's startup configuration, resulting in the following benefits:
•Having a persistent self-signed certificate stored in the router's startup configuration (NVRAM) lessens the opportunity for an attacker to substitute an unauthorized certificate because the browser is able to compare the certificate offered by the router with the previously saved certificate and warn you if the certificate has changed.
•Having a persistent self-signed certificate stored in the router's startup configuration eliminates the user intervention that is necessary to accept the certificate every time that the router reloads.
•Because user intervention is no longer necessary to accept the certificate, the secure connection process is faster.
Persistent Self-Signed Certificates Configuration Guidelines and Restrictions
When configuring persistent self-signed certificates, follow these guidelines and restrictions:
•You must load an image that supports SSL.
•You can configure only one trustpoint for a persistent self-signed certificate.
Configuring a Trustpoint and Specifying Self-Signed Certificate Parameters

Note This section is optional because if you enable the Secure HTTP (HTTPS) server, it generates a self-signed certificate automatically using default values. To specify parameters, you must create a trustpoint and configure it. To use default values, delete any existing self-signed trustpoints. Deleting all self-signed trustpoints causes the HTTPS server to generate a persistent self-signed certificate using default values as soon as it is enabled.
To configure a trustpoint and specify self-signed certificate parameters, perform this task beginning in global configuration mode:
Enabling the HTTPS Server
To enable the HTTPS server, perform this task beginning in global configuration mode:

Note You must enter a write memory command to save the configuration. This command also saves the self-signed certificate and the HTTPS server in enabled mode.
Verifying the Persistent Self-Signed Certificate Configuration
To verify that a self-signed certificate and a trustpoint have been created, use the show crypto pki certificates, show crypto mypubkey rsa, and the show crypto pki trustpoints commands.
The show crypto pki certificates command displays information about your certificate, the CA certificate, and any registration authority certificates:
Router# show crypto pki certificates
Router Self-Signed Certificate
Status: Available
Certificate Serial Number: 01
Certificate Usage: General Purpose
Issuer:
cn=IOS-Self-Signed-Certificate-3326000105
Subject:
Name: IOS-Self-Signed-Certificate-3326000105
cn=IOS-Self-Signed-Certificate-3326000105
Validity Date:
start date: 19:14:14 GMT Dec 21 2004
end date: 00:00:00 GMT Jan 1 2020
Associated Trustpoints: TP-self-signed-3326000105

Note The number 3326000105 above is the router's serial number and varies depending on the router's actual serial number.
The show crypto mypubkey rsa command displays information about the key pair corresponding to the self-signed certificate:
Router# show crypto mypubkey rsa
% Key pair was generated at: 19:14:10 GMT Dec 21 2004
Key name: TP-self-signed-3326000105
Usage: General Purpose Key
Key is not exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B88F70
6BC78B6D 67D6CFF3 135C1D91 8F360292 CA44A032 5AC1A8FD 095E4865 F8C95A2B
BFD1C2B7 E64A3804 9BBD7326 207BD456 19BAB78B D075E78E 00D2560C B09289AE
6DECB8B0 6672FB3A 5CDAEE92 9D4C4F71 F3BCB269 214F6293 4BA8FABF 9486BCFC
2B941BCA 550999A7 2EFE12A5 6B7B669A 2D88AB77 39B38E0E AA23CB8C B7020301 0001
% Key pair was generated at: 19:14:13 GMT Dec 21 2004
Key name: TP-self-signed-3326000105.server
Usage: Encryption Key
Key is not exportable.
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C5680E 89777B42
463E5783 FE96EA9E F446DC7B 70499AF3 EA266651 56EE29F4 5B003D93 2FC9F81D
8A46E12F 3FBAC2F3 046ED9DD C5F27C20 1BBA6B9B 08F16E45 C34D6337 F863D605
34E30F0E B4921BC5 DAC9EBBA 50C54AA0 BF551BDD 88453F50 61020301 0001

Note The second key pair with the name TP-self-signed-3326000105.server is the SSH key pair and is generated once any key pair is created on the router and SSH starts up.
The show crypto pki trustpoints command displays the trustpoints that are configured in the router:
Router# show crypto pki trustpoints
Trustpoint local:
Subject Name:
serialNumber=C63EBBE9+ipaddress=10.3.0.18+hostname=test.cisco.com
Serial Number: 01
Persistent self-signed certificate trust point
For complete configuration information for persistent self-signed certificates, refer to this URL:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtpsscer.html
For persistent self-signed certificates configuration examples, see the "Persistent Self-Signed Certificates Configuration Examples" section.
Configuration Examples
This section provides examples of the following configurations:
•Multiple RSA Key Pairs Configuration Example
•Protected Private Key Storage Configuration Examples
•Trustpoint CA Configuration Example
•Query Mode Definition Per Trustpoint Configuration Example
•Local Certificate Storage Location Configuration Example
•Direct HTTP Enrollment with CA Servers Configuration Examples
•Manual Certificate Enrollment Configuration Examples
•Certificate Autoenrollment Configuration Example
•Key Rollover for Certificate Renewal Configuration Examples
•PKI: Query Multiple Servers During Certificate Revocation Check (CDP Override) Configuration Example
•Online Certificate Status Protocol Configuration Examples
•Certificate Security Attribute-Based Access Control Configuration Example
•PKI AAA Authorization Using the Entire Subject Name Configuration Example
•Source Interface Selection for Outgoing Traffic with Certificate Authority Configuration Example
•Persistent Self-Signed Certificates Configuration Examples

Note The following examples use commands at the level of Cisco IOS Release 12.2(33)SXH.
As of Cisco IOS Release 12.2(33)SXH, the crypto engine subslot command used in previous releases has been replaced with the crypto engine slot command (of the form crypto engine slot slot {inside | outside}). The crypto engine subslot command is no longer supported. When upgrading, ensure that this command has been modified in your start-up configuration to avoid extended maintenance time.
Multiple RSA Key Pairs Configuration Example
The following example is a sample trustpoint configuration that specifies the RSA key pair exampleCAkeys:
Router(config)# crypto key generate rsa general-keys label exampleCAkeys
Router(config)# crypto pki trustpoint exampleCAkeys
Router(ca-trustpoint)# enrollment url http://exampleCAkeys/certsrv/mscep/mscep.dll
Router(ca-trustpoint)# rsakeypair exampleCAkeys 1024 1024
Protected Private Key Storage Configuration Examples
This section contains the following configuration examples:
•Encrypted Key Configuration Example
•Locked Key Configuration Example
Encrypted Key Configuration Example
The following example shows how to encrypt the pki1-72a.cisco.com RSA key:
Router(config)# crypto key encrypt rsa name pki1-72a.cisco.com passphrase cisco1234
Router(config)# exit
Locked Key Configuration Example
The following example shows how to lock the pki1-72a.cisco.com key:
Router# crypto key lock rsa name pki1-72a.cisco.com passphrase cisco1234
Trustpoint CA Configuration Example
The following example shows how to declare the CA named kahului and specify characteristics for the trustpoint CA:
Router(config)# crypto pki trustpoint kahului
Router(ca-trustpoint)# enrollment url http://kahului
Router(ca-trustpoint)# crl query ldap://kahului
Query Mode Definition Per Trustpoint Configuration Example
The following configuration example shows a trustpoint CA that uses query mode:
Router(config)# crypto pki trustpoint trustpoint1
Router(ca-trustpoint)# enrollment url http://ca-server1
Router(ca-trustpoint)# crl query http://ca-server1
Router(ca-trustpoint)# query certificate
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate trustpoint1
Router(config)# crypto key generate rsa
Router(config)# crypto pki enroll trustpoint1
Local Certificate Storage Location Configuration Example
The following example shows how to store certificates to the certs subdirectory. Note that the certs subdirectory does not exist and is automatically created.
Router(config)# crypto pki certificate storage disk0:/certs
Requested directory does not exist -- created
Certificates will be stored in disk0:/certs/
Router(config)# end
Router# write
*May 27 02:09:00:%SYS-5-CONFIG_I:Configured from console by consolemem
Building configuration...
[OK]
Router# directory disk0:/certs
Directory of disk0:/certs/
14 -rw- 707 May 27 2005 02:09:02 +00:00 ioscaroot#7401CA.cer
15 -rw- 863 May 27 2005 02:09:02 +00:00 msca-root#826E.cer
16 -rw- 759 May 27 2005 02:09:02 +00:00 msca-root#1BA8CA.cer
17 -rw- 863 May 27 2005 02:09:02 +00:00 msca-root#75B8.cer
18 -rw- 1149 May 27 2005 02:09:02 +00:00 storagename#6500CA.cer
19 -rw- 863 May 27 2005 02:09:02 +00:00 msca-root#83EE.cer
47894528 bytes total (20934656 bytes free)
! The certificate files are now on disk0/certs:
Direct HTTP Enrollment with CA Servers Configuration Examples
This section provides the following configuration examples:
•Enrollment Profile for a Client Switch Configuration Example
•Enrollment Profile for a Client Switch Already Enrolled with a Third-Party Vendor CA Example
Enrollment Profile for a Client Switch Configuration Example
The following example show how to configure an enrollment profile for direct HTTP enrollment with a CA server:
Router(config)# crypto pki trustpoint Entrust
Router(ca-trustpoint)# enrollment profile E
Router(ca-trustpoint)# exit
Router(config)# crypto pki profile enrollment E
Router(ca-profile-enroll)# authentication url http://entrust:81
Router(ca-profile-enroll)# authentication command GET /certs/cacert.der
Router(ca-profile-enroll)# enrollment url http://entrust:81/cda-cgi/clientcgi.exe
Router(ca-profile-enroll)# enrollment command POST reference_number=$P2&authcode=$P1
&retrievedAs=rawDER&action=getServerCert&pkcs10Request=$REQ
Router(ca-profile-enroll)# parameter 1 value aaaa-bbbb-cccc
Router(ca-profile-enroll)# parameter 2 value 5001
Router(config)# crypto ca profile enrollment E
Router(ca-profile-enroll)# authentication url http://ca-server.example.com
Router(ca-profile-enroll)# authentication command GET $P1
Router(ca-profile-enroll)# enrollment url
Router(ca-profile-enroll)# enrollment command ^C
POST action=getServerCert
&pkcs10Request=$REQ
&reference_number=$P2
&authcode=P3
&retrievedAs=rawDER
^C
Router(ca-profile-enroll)# parameter 1 value cacert.crt
Router(ca-profile-enroll)# parameter 2 prompt Enter the Reference Number:
Router(ca-profile-enroll)# parameter 3 prompt Enter the Auth Code:
Enrollment Profile for a Client Switch Already Enrolled with a Third-Party Vendor CA Example
The following example shows how to configure the following tasks on the client switch:
•Define the msca-root trustpoint that points to the third-party vendor CA and enroll and authenticate the client with the third-party vendor CA.
•Define cs trustpoint for the Cisco IOS CA.
•Define enrollment profile "cs1," which points to Cisco IOS CA, and mention (via the enrollment credential command) that msca-root is being initially enrolled with the Cisco IOS CA.
! Define trustpoint "msca-root" for non-Cisco IOS CA.
Router(config)# crypto pki trustpoint msca-root
Router(ca-trustpoint)# enrollment mode ra
Router(ca-trustpoint)# enrollment url http://msca-root:80/certsrv/mscep/mscep.dll
Router(ca-trustpoint)# ip-address FastEthernet2/0
Router(ca-trustpoint)# revocation-check crl
! Configure trustpoint "cs" for Cisco IOS CA.
Router(config)# crypto pki trustpoint cs
Router(ca-trustpoint)# enrollment profile cs1
Router(ca-trustpoint)# revocation-check crl
! Define enrollment profile "cs1."
Router(config)# crypto pki profile enrollment cs1
Router(ca-profile-enroll)# enrollment url http://cs:80
Router(ca-profile-enroll)# enrollment credential msca-root
Certificate Server Automatically Accepting Enrollment Requests Only from the Client Switch Configuration Example
The following example shows how to configure the certificate server, and enter the grant auto trustpoint command to instruct the certificate server to accept enrollment requests only from clients who are already enrolled with msca-root trustpoint:
Router(config)# crypto pki server cs
Router(cs-server)# database level minimum
Router(cs-server)# database url nvram:
Router(cs-server)# issuer-name CN=cs
Router(cs-server)# grant auto trustpoint msca-root
Router(config)# crypto pki trustpoint cs
Router(ca-trustpoint)# revocation-check crl
Router(ca-trustpoint)# rsakeypair cs
Router(ca-trustpoint)# crypto pki trustpoint msca-root
Router(ca-trustpoint)# enrollment mode ra
Router(ca-trustpoint)# enrollment url http://msca-root:80/certsrv/mscep/mscep.dll
Router(ca-trustpoint)# revocation-check crl
Manual Certificate Enrollment Configuration Examples
This section provides the following manual certificate enrollment configuration examples:
•Manual Certificate Enrollment Using TFTP Configuration Example
•Manual Certificate Enrollment Using Cut-and-Paste Configuration Example
Manual Certificate Enrollment Using TFTP Configuration Example
The following example shows the configuration of manual certificate enrollment using TFTP:
Router(config)# crypto pki trustpoint MS
Router(ca-trustpoint)# enrollment url tftp://CA-Server/TFTPfiles/switch1
Router(ca-trustpoint)# crypto pki authenticate MS
Router(ca-trustpoint)# exit
Router(config)# crypto pki enroll MS
Router(config)# crypto pki import MS certificate
Manual Certificate Enrollment Using Cut-and-Paste Configuration Example
The following example shows how to configure manual cut-and-paste certificate enrollment. In this example, the name of the trustpoint CA is MS, and the crypto pki import command is entered twice because usage keys (signature and encryption keys) are used.
Router(config)# crypto pki trustpoint MS
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# crypto pki authenticate MS
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIICNDCCAd6gAwIBAgIQOsCmXpVHwodKryRoqULV7jANBgkqhkiG9w0BAQUFADA5
MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczESMBAGA1UEAxMJ
bXNjYS1yb290MB4XDTAyMDIxNDAwNDYwMVoXDTA3MDIxNDAwNTQ0OFowOTELMAkG
A1UEBhMCVVMxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxEjAQBgNVBAMTCW1zY2Et
cm9vdDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCix8nIGFg+wvy3BjFbVi25wYoG
K2N0HWWHpqxFuFhqyBnIC0OshIn9CtrdN3JvUNHr0NIKocEwNKUGYmPwWGTfAgMB
AAGjgcEwgb4wCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE
FKIacsl6dKAfuNDVQymlSp7esf8jMG0GA1UdHwRmMGQwL6AtoCuGKWh0dHA6Ly9t
c2NhLXJvb3QvQ2VydEVucm9sbC9tc2NhLXJvb3QuY3JsMDGgL6AthitmaWxlOi8v
XFxtc2NhLXJvb3RcQ2VydEVucm9sbFxtc2NhLXJvb3QuY3JsMBAGCSsGAQQBgjcV
AQQDAgEAMA0GCSqGSIb3DQEBBQUAA0EAeuZkZMX9qkoLHfETYTpVWjZPQbBmwNRA
oJDSdYdtL3BcI/uLL5q7EmODyGfLyMGxuhQYx5r/40aSQgLCqBq+yg==
-----END CERTIFICATE-----
Certificate has the following attributes:
Fingerprint:D6C12961 CD78808A 4E02193C 0790082A
% Do you accept this certificate? [yes/no]:y
Trustpoint CA certificate accepted.
% Certificate successfully imported
Router(config)#
Router(config)# crypto pki enroll MS
% Start certificate enrollment..
% The subject name in the certificate will be:Router.cisco.com
% Include the router serial number in the subject name? [yes/no]:n
% Include an IP address in the subject name? [no]:n
Display Certificate Request to terminal? [yes/no]:y
Signature key certificate request -
Certificate Request follows:
MIIBhTCB7wIBADAlMSMwIQYJKoZIhvcNAQkCFhRTYW5kQmFnZ2VyLmNpc2NvLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxdhXFDiWAn/hIZs9zfOtssKA
daoWYu0ms9Fe/Pew01dh14vXdxgacstOs2Pr5wk6jLOPxpvxOJPWyQM6ipLmyVxv
ojhyLTrVohrh6Dnqcvk+G/5ohss9o9RxvONwx042pQchFnx9EkMuZC7evwRxJEqR
mBHXBZ8GmP3jYQsjS8MCAwEAAaAhMB8GCSqGSIb3DQEJDjESMBAwDgYDVR0PAQH/
BAQDAgeAMA0GCSqGSIb3DQEBBAUAA4GBAMT6WtyFw95POY7UtF+YIYHiVRUf4SCq
hRIAGrljUePLo9iTqyPU1Pnt8JnIZ5P5BHU3MfgP8sqodaWub6mubkzaohJ1qD06
O87fnLCNid5Tov5jKogFHIki2EGGZxBosUw9lJlenQdNdDPbJc5LIWdfDvciA6jO
Nl8rOtKnt8Q+
---End - This line not part of the certificate request---
Redisplay enrollment request? [yes/no]:
Encryption key certificate request -
Certificate Request follows:
MIIBhTCB7wIBADAlMSMwIQYJKoZIhvcNAQkCFhRTYW5kQmFnZ2VyLmNpc2NvLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwG60QojpDbzbKnyj8FyTiOcv
THkDP7XD4vLT1XaJ409z0gSIoGnIcdFtXhVlBWtpq3/O9zYFXr1tH+BMCRQi3Lts
0IpxYa3D9iFPqev7SPXpsAIsY8a6FMq7TiwLObqiQjLKL4cbuV0Frjl0Yuv5A/Z+
kqMOm7c+pWNWFdLe9lsCAwEAAaAhMB8GCSqGSIb3DQEJDjESMBAwDgYDVR0PAQH/
BAQDAgUgMA0GCSqGSIb3DQEBBAUAA4GBACF7feURj/fJMojPBlR6fa9BrlMJx+2F
H91YM/CIiz2n4mHTeWTWKhLoT8wUfa9NGOk7yi+nF/F7035twLfq6n2bSCTW4aem
8jLMMaeFxwkrV/ceQKrucmNC1uVx+fBy9rhnKx8j60XE25tnp1U08r6om/pBQABU
eNPFhozcaQ/2
---End - This line not part of the certificate request---
Redisplay enrollment request? [yes/no]:
n
Router(config)#crypto pki import MS certificate
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
MIIDajCCAxSgAwIBAgIKFN7C6QAAAAAMRzANBgkqhkiG9w0BAQUFADA5MQswCQYD
VQQGEwJVUzEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczESMBAGA1UEAxMJbXNjYS1y
b290MB4XDTAyMDYwODAxMTY0MloXDTAzMDYwODAxMjY0MlowJTEjMCEGCSqGSIb3
DQEJAhMUU2FuZEJhZ2dlci5jaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAMXYVxQ4lgJ/4SGbPc3zrbLCgHWqFmLtJrPRXvz3sNNXYdeL13cYGnLL
TrNj6+cJOoyzj8ab8TiT1skDOoqS5slcb6I4ci061aIa4eg56nL5Phv+aIbLPaPU
cbzjcMdONqUHIRZ8fRJDLmQu3r8EcSRKkZgR1wWfBpj942ELI0vDAgMBAAGjggHM
MIIByDALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFL8Quz8dyz4EGIeKx9A8UMNHLE4s
MHAGA1UdIwRpMGeAFKIacsl6dKAfuNDVQymlSp7esf8joT2kOzA5MQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczESMBAGA1UEAxMJbXNjYS1yb290
ghA6wKZelUfCh0qvJGipQtXuMCIGA1UdEQEB/wQYMBaCFFNhbmRCYWdnZXIuY2lz
Y28uY29tMG0GA1UdHwRmMGQwL6AtoCuGKWh0dHA6Ly9tc2NhLXJvb3QvQ2VydEVu
cm9sbC9tc2NhLXJvb3QuY3JsMDGgL6AthitmaWxlOi8vXFxtc2NhLXJvb3RcQ2Vy
dEVucm9sbFxtc2NhLXJvb3QuY3JsMIGUBggrBgEFBQcBAQSBhzCBhDA/BggrBgEF
BQcwAoYzaHR0cDovL21zY2Etcm9vdC9DZXJ0RW5yb2xsL21zY2Etcm9vdF9tc2Nh
LXJvb3QuY3J0MEEGCCsGAQUFBzAChjVmaWxlOi8vXFxtc2NhLXJvb3RcQ2VydEVu
cm9sbFxtc2NhLXJvb3RfbXNjYS1yb290LmNydDANBgkqhkiG9w0BAQUFAANBAJo2
r6sHPGBdTQX2EDoJpR/A2UHXxRYqVSHkFKZw0z31r5JzUM0oPNUETV7mnZlYNVRZ
CSEX/G8boi3WOjz9wZo=
% Router Certificate successfully imported
Router(config)#
Router(config)# crypto pki import MS certificate
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
MIIDajCCAxSgAwIBAgIKFN7OBQAAAAAMSDANBgkqhkiG9w0BAQUFADA5MQswCQYD
VQQGEwJVUzEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczESMBAGA1UEAxMJbXNjYS1y
b290MB4XDTAyMDYwODAxMTY0NVoXDTAzMDYwODAxMjY0NVowJTEjMCEGCSqGSIb3
DQEJAhMUU2FuZEJhZ2dlci5jaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAMButEKI6Q282yp8o/Bck4jnL0x5Az+1w+Ly09V2ieNPc9IEiKBpyHHR
bV4VZQVraat/zvc2BV69bR/gTAkUIty7bNCKcWGtw/YhT6nr+0j16bACLGPGuhTK
u04sCzm6okIyyi+HG7ldBa45dGLr+QP2fpKjDpu3PqVjVhXS3vZbAgMBAAGjggHM
MIIByDALBgNVHQ8EBAMCBSAwHQYDVR0OBBYEFPDO29oRdlEUSgBMg6jZR+YFRWlj
MHAGA1UdIwRpMGeAFKIacsl6dKAfuNDVQymlSp7esf8joT2kOzA5MQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczESMBAGA1UEAxMJbXNjYS1yb290
ghA6wKZelUfCh0qvJGipQtXuMCIGA1UdEQEB/wQYMBaCFFNhbmRCYWdnZXIuY2lz
Y28uY29tMG0GA1UdHwRmMGQwL6AtoCuGKWh0dHA6Ly9tc2NhLXJvb3QvQ2VydEVu
cm9sbC9tc2NhLXJvb3QuY3JsMDGgL6AthitmaWxlOi8vXFxtc2NhLXJvb3RcQ2Vy
dEVucm9sbFxtc2NhLXJvb3QuY3JsMIGUBggrBgEFBQcBAQSBhzCBhDA/BggrBgEF
BQcwAoYzaHR0cDovL21zY2Etcm9vdC9DZXJ0RW5yb2xsL21zY2Etcm9vdF9tc2Nh
LXJvb3QuY3J0MEEGCCsGAQUFBzAChjVmaWxlOi8vXFxtc2NhLXJvb3RcQ2VydEVu
cm9sbFxtc2NhLXJvb3RfbXNjYS1yb290LmNydDANBgkqhkiG9w0BAQUFAANBAHaU
hyCwLirUghNxCmLzXRG7C3W1j0kSX7a4fX9OxKR/Z2SoMjdMNPPyApuh8SoT2zBP
ZKjZU2WjcZG/nZF4W5k=
% Router Certificate successfully imported
Certificate Autoenrollment Configuration Example
The following example shows how to configure the switch to autoenroll with a CA on start-up:
Router(config)# crypto pki trustpoint frog
Router(ca-trustpoint)# enrollment url http://frog.phoobin.com/
Router(ca-trustpoint)# subject-name OU=Spiral Dept., O=tiedye.com
Router(ca-trustpoint)# ip-address ethernet-0
Router(ca-trustpoint)# auto-enroll regenerate
Router(ca-trustpoint)# password revokeme
Router(ca-trustpoint)# rsa-key frog 2048
!
Router(config)# crypto pki certificate chain frog
Router(config-cert-chain)# certificate ca 0B
30820293 3082023D A0030201 0202010B 300D0609 2A864886 F70D0101 04050030
79310B30 09060355 04061302 5553310B 30090603 55040813 02434131 15301306
0355040A 130C4369 73636F20 53797374 656D3120 301E0603 55040B13 17737562
6F726420 746F206B 6168756C 75692049 50495355 31243022 06035504 03131B79
6E692D75 31302043 65727469 66696361 7465204D 616E6167 6572301E 170D3030
30373134 32303536 32355A17 0D303130 37313430 31323834 335A3032 310E300C
06035504 0A130543 6973636F 3120301E 06092A86 4886F70D 01090216 11706B69
2D343562 2E636973 636F2E63 6F6D305C 300D0609 2A864886 F70D0101 01050003
4B003048 024100B3 0512A201 3B4243E1 378A9703 8AC5E3CE F77AF987 B5A422C4
15E947F6 70997393 70CF34D6 63A86B9C 4347A81A 0551FC02 ABA62360 01EF7DD2
6C136AEB 3C6C3902 03010001 A381F630 81F3300B 0603551D 0F040403 02052030
1C060355 1D110415 30138211 706B692D 3435622E 63697363 6F2E636F 6D301D06
03551D0E 04160414 247D9558 169B9A21 23D289CC 2DDA2A9A 4F77C616 301F0603
551D2304 18301680 14BD742C E892E819 1D551D91 683F6DB2 D8847A6C 73308185
0603551D 1F047E30 7C307AA0 3CA03AA4 38303631 0E300C06 0355040A 13054369
73636F31 24302206 03550403 131B796E 692D7531 30204365 72746966 69636174
65204D61 6E616765 72A23AA4 38303631 0E300C06 0355040A 13054369 73636F31
24302206 03550403 131B796E 692D7531 30204365 72746966 69636174 65204D61
6E616765 72300D06 092A8648 86F70D01 01040500 03410015 BC7CECF9 696697DF
E887007F 7A8DA24F 1ED5A785 C5C60452 47860061 0C18093D 08958A77 5737246B
0A25550A 25910E27 8B8B428E 32F8D948 3DD1784F 954C70
quit
Key Rollover for Certificate Renewal Configuration Examples
This section contains the following examples:
•Certificate Autoenrollment with Key Rollover Configuration Example
•Manual Certificate Enrollment with Key Rollover Configuration Example
Certificate Autoenrollment with Key Rollover Configuration Example
The following example shows how to configure the switch to autoenroll with the CA named trustme1 on startup. In this example, the regenerate keyword is specified, so a new key will be generated for the certificate. The renewal percentage is configured as 90 so if the certificate has a lifetime of one year, a new certificate is requested 36.5 days before the old certificate expires. The changes made to the running configuration are saved to the NVRAM startup configuration because autoenrollment will not update NVRAM if the running configuration has been modified but not written to NVRAM.
Router(config)# crypto pki trustpoint trustme1
Router(ca-trustpoint)# enrollment url http://trustme1.company.com/
Router(ca-trustpoint)# subject-name OU=Spiral Dept., O=tiedye.com
Router(ca-trustpoint)# ip-address ethernet0
Router(ca-trustpoint)# serial-number none
Router(ca-trustpoint)# auto-enroll 90 regenerate
Router(ca-trustpoint)# password revokeme
Router(ca-trustpoint)# rsakeypair trustme1 2048
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate trustme1
Manual Certificate Enrollment with Key Rollover Configuration Example
The following example shows how to configure key rollover to regenerate new keys with a manual certificate enrollment from the CA named trustme2:
Router(config)# crypto pki trustpoint trustme2
Router(ca-trustpoint)# enrollment url http://trustme2.company.com/
Router(ca-trustpoint)# subject-name OU=Spiral Dept., O=tiedye.com
Router(ca-trustpoint)# ip-address ethernet0
Router(ca-trustpoint)# serial-number none
Router(ca-trustpoint)# regenerate
Router(ca-trustpoint)# password revokeme
Router(ca-trustpoint)# rsakeypair trustme2 2048
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate trustme2
Router(config)# crypto pki enroll trustme2
Router(config)# exit
PKI: Query Multiple Servers During Certificate Revocation Check (CDP Override) Configuration Example
The following example uses the match certificate override cdp command to override the CDPs for the certificate map named Group1 defined in a crypto pki certificate map command:
Router(config)# crypto pki certificate map Group1 10
Router(ca-certificate-map)# subject-name co ou=WAN
Router(ca-certificate-map)# subject-name co o=Cisco
Router(config)# crypto pki trustpoint pki
Router(ca-trustpoint)# match certificate Group1 override cdp url http://server.cisco.com
Online Certificate Status Protocol Configuration Examples
This section provides the following configuration examples:
•OCSP Server Configuration Example
•CRL Then OCSP Server Configuration Example
•Specific OCSP Server Configuration Example
OCSP Server Configuration Example
The following example shows how to configure the switch to use the OCSP server that is specified in the AIA extension of the certificate:
Router(config)# crypto pki trustpoint mytp
Router(ca-trustpoint)# revocation-check ocsp
CRL Then OCSP Server Configuration Example
The following example shows how to configure the switch to download the CRL from the certificate distribution point (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 mytp
Router(ca-trustpoint)# revocation-check crl ocsp
Specific OCSP Server Configuration Example
The following example shows how to configure your switch to use the OCSP server at the HTTP URL http://myocspserver:81. If the server is down, revocation check will be ignored.
Router(config)# crypto pki trustpoint mytp
Router(ca-trustpoint)# ocsp url http://myocspserver:81
Router(ca-trustpoint)# revocation-check ocsp none
Certificate Security Attribute-Based Access Control Configuration Example
The following example shows how to configure a certificate-based ACL:
Router(config)# crypto pki certificate map Group 10
Router(ca-certificate-map)# subject-name co Cisco
Router(config-cert-map)# exit
Router(config)# crypto pki trustpoint Access
Router(ca-trustpoint)# match certificate Group
Router(ca-trustpoint)# exit
PKI AAA Authorization Using the Entire Subject Name Configuration Example
The following example shows that the entire subject name of the certificate is to be used for PKI AAA authorization:
Router(config)# aaa new-model
Router(config)# aaa authorization network tac-o group tacacs+
Router(config)# crypto pki trustpoint test
Router(ca-trustpoint)# enrollment url http://caserver:80
Router(ca-trustpoint)# revocation-check crl
Router(ca-trustpoint)# exit
Router(ca-trustpoint)# authorization list tac-o
Router(ca-trustpoint)# authorization username subjectname all
Router(config)# tacacs-server host 20.2.2.2 key a_secret_key
Source Interface Selection for Outgoing Traffic with Certificate Authority Configuration Example
In the following example, the switch is located in a branch office. The switch uses IP Security (IPsec) to communicate with the main office. Ethernet 1 is the outside interface that connects to the Internet Service Provider (ISP). Ethernet 0 is the interface connected to the LAN of the branch office. To access the CA server located in the main office, the switch must send its IP datagrams out interface Ethernet 1 (address 10.2.2.205) using the IPsec tunnel. Address 10.2.2.205 is assigned by the ISP. Address 10.2.2.205 is not a part of the branch office or main office.
The CA cannot access any address outside the company because of a firewall. The CA sees a message coming from 10.2.2.205 and cannot respond (that is, the CA does not know that the switch is located in a branch office at address 10.1.1.1, which it is able to reach).
Adding the source interface command tells the switch to use address 10.1.1.1 as the source address of the IP datagram that it sends to the CA. The CA is able to respond to 10.1.1.1.
This example is configured using the source interface command and the interface addresses as described above.
Router(config)# crypto pki trustpoint ms-ca
Router(ca-trustpoint)# enrollment url http://ms-ca:80/certsrv/mscep/mscep.dll
Router(ca-trustpoint)# source interface ethernet0
Router(config)# interface ethernet 0
Router(config-if)# description inside interface
Router(config-if)# ip address 10.1.1.1 255.255.255.0
Router(config)# interface ethernet 1
Router(config-if)# description outside interface
Router(config-if)# ip address 10.2.2.205 255.255.255.0
Router(config-if)# crypto map main-office
Persistent Self-Signed Certificates Configuration Examples
The following examples show how to configure a persistent self-signed certificate:
•Trustpoint and Self-Signed Certificate Configuration Example
•Enabling the HTTPS Server Configuration Example
Trustpoint and Self-Signed Certificate Configuration Example
The following example shows how to configure a trustpoint and a self-signed certificate. In this example, a trustpoint named local is declared, its enrollment is requested, and a self-signed certificate with an IP address is generated.
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# crypto pki trustpoint local
Router(ca-trustpoint)# enrollment selfsigned
Router(ca-trustpoint)# end
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# crypto pki enroll local
Nov 29 20:51:13.067: %SSH-5-ENABLED: SSH 1.99 has been enabled
Nov 29 20:51:13.267: %CRYPTO-6-AUTOGEN: Generated new 512 bit key pair
% Include the router serial number in the subject name? [yes/no]: yes
% Include an IP address in the subject name? [no]: yes
Enter Interface name or IP Address[]: ethernet 0
Generate Self Signed Router Certificate? [yes/no]: yes
Router Self Signed Certificate successfully created

Note A switch can have only one self-signed certificate. If you attempt to enroll a trustpoint configured for a self-signed certificate and one already exists, you receive a notification and are asked if you want to replace it. If so, a new self-signed certificate is generated to replace the existing one.
Enabling the HTTPS Server Configuration Example
In the following example, the HTTPS server is enabled and a default trustpoint is generated because one was not previously configured:
Router(config)# ip http secure-server
% Generating 1024 bit RSA keys ...[OK]
*Dec 21 19:14:15.421:%PKI-4-NOAUTOSAVE:Configuration was modified. Issue "write memory"
to save new certificate
Router(config)#

Note You must save the configuration to NVRAM if you want to keep the self-signed certificate and have the HTTPS server enabled following switch reloads.
The following message also appears:
*Dec 21 19:14:10.441:%SSH-5-ENABLED:SSH 1.99 has been enabled
Router(config)#

Note Creation of the key pair used with the self-signed certificate causes the Secure Shell (SSH) server to start. This behavior cannot be suppressed. You may want to modify your access control lists (ACLs) to permit or deny SSH access to the router.