Implementing Certification Authority Interoperability
CA interoperability permits devices and CAs to communicate so that your device can obtain and use digital certificates from the CA. Although IPSec can be implemented in your network without the use of a CA, using a CA provides manageability and scalability for IPSec.
Note |
IPSec will be supported in a future release. |
Feature History for Implementing Certification Authority Interoperability
Release |
Modification |
---|---|
Release 6.0 |
This feature was introduced. |
Prerequisites for Implementing Certification Authority
The following prerequisites are required to implement CA interoperability:
-
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
-
You must install and activate the Package Installation Envelope (PIE) for the security software.
For detailed information about optional PIE installation, refer to the System Management Guide.
-
You need to have a CA available to your network before you configure this interoperability feature. The CA must support Cisco Systems PKI protocol, the simple certificate enrollment protocol (SCEP) (formerly called certificate enrollment protocol [CEP]).
Restrictions for Implementing Certification Authority
Configure Router Hostname and IP Domain Name
This task configures a router hostname and IP domain name.
You must configure the hostname and IP domain name of the router if they have not already been configured. The hostname and IP domain name are required because the router assigns a fully qualified domain name (FQDN) to the keys and certificates used by IPSec, and the FQDN is based on the hostname and IP domain name you assign to the router. For example, a certificate named router20.example.com is based on a router hostname of router20 and a router IP domain name of example.com.
Procedure
Step 1 |
configure Example:
Enters mode. |
Step 2 |
hostname name Example:
Configures the hostname of the router. |
Step 3 |
domain name domain-name Example:
Configures the IP domain name of the router. |
Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Generate RSA Key Pair
This task generates an RSA key pair.
RSA key pairs are used to sign and encrypt IKE key management messages and are required before you can obtain a certificate for your router.
Procedure
Step 1 |
crypto key generate rsa [usage keys | general-keys] [keypair-label] Example:
Generates RSA key pairs.
|
Step 2 |
crypto key zeroize rsa [keypair-label] Example:
(Optional) Deletes all RSAs from the router.
|
Step 3 |
show crypto key mypubkey rsa Example:
(Optional) Displays the RSA public keys for your router. |
Import Public Key to the Router
This task imports a public key to the router.
A public key is imported to the router to authenticate the user.
Procedure
Step 1 |
crypto key import authentication rsa [usage keys | general-keys] [keypair-label] Example:
Generates RSA key pairs.
|
Step 2 |
show crypto key mypubkey rsa Example:
(Optional) Displays the RSA public keys for your router. |
Declare Certification Authority and Configure Trusted Point
This task declares a CA and configures a trusted point.
Procedure
Step 1 |
configure Example:
Enters mode. |
||
Step 2 |
crypto ca trustpoint ca-name Example:
Declares a CA.
|
||
Step 3 |
enrollment url CA-URL Example:
Specifies the URL of the CA.
|
||
Step 4 |
query url LDAP-URL Example:
(Optional) Specifies the location of the LDAP server if your CA system supports the LDAP protocol. |
||
Step 5 |
enrollment retry period minutes Example:
(Optional) Specifies a retry period.
|
||
Step 6 |
enrollment retry count number Example:
(Optional) Specifies how many times the router continues to send unsuccessful certificate requests before giving up.
|
||
Step 7 |
rsakeypair keypair-label Example:
(Optional) Specifies a named RSA key pair generated using the crypto key generate rsa command for this trustpoint.
|
||
Step 8 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Authenticate CA
This task authenticates the CA to your router.
The router must authenticate the CA by obtaining the self-signed certificate of the CA, which contains the public key of the CA. Because the certificate of the CA is self-signed (the CA signs its own certificate), manually authenticate the public key of the CA by contacting the CA administrator to compare the fingerprint of the CA certificate.
Procedure
Step 1 |
crypto ca authenticate ca-name Example:
Authenticates the CA to your router by obtaining a CA certificate, which contains the public key for the CA. |
Step 2 |
show crypto ca certificates Example:
(Optional) Displays information about the CA certificate. |
Request Your Own Certificates
This task requests certificates from the CA.
You must obtain a signed certificate from the CA for each of your router’s RSA key pairs. If you generated general-purpose RSA keys, your router has only one RSA key pair and needs only one certificate. If you previously generated special usage RSA keys, your router has two RSA key pairs and needs two certificates.
Procedure
Step 1 |
crypto ca enroll ca-name Example:
Requests certificates for all of your RSA key pairs.
|
Step 2 |
show crypto ca certificates Example:
(Optional) Displays information about the CA certificate. |
Configure Certificate Enrollment Using Cut-and-Paste
This task declares the trustpoint certification authority (CA) that your router should use and configures that trustpoint CA for manual enrollment by using cut-and-paste.
Procedure
Step 1 |
configure Example:
Enters mode. |
||
Step 2 |
crypto ca trustpoint ca-name Example:
Declares the CA that your router should use and enters trustpoint configuration mode.
|
||
Step 3 |
enrollment terminal Example:
Specifies manual cut-and-paste certificate enrollment. |
||
Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
||
Step 5 |
crypto ca authenticate ca-name Example:
Authenticates the CA by obtaining the certificate of the CA.
|
||
Step 6 |
crypto ca enroll ca-name Example:
Obtains the certificates for your router from the CA.
|
||
Step 7 |
crypto ca import ca- name certificate Example:
Imports a certificate manually at the terminal.
|
||
Step 8 |
show crypto ca certificates Example:
Displays information about your certificate and the CA certificate. |
The following example shows how to configure CA interoperability.
Comments are included within the configuration to explain various commands.
configure
hostname myrouter
domain name mydomain.com
end
Uncommitted changes found, commit them? [yes]:yes
crypto key generate rsa mykey
The name for the keys will be:mykey
Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keypair
Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [1024]:
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]
show crypto key mypubkey rsa
Key label:mykey
Type :RSA General purpose
Size :1024
Created :17:33:23 UTC Thu Sep 18 2003
Data :
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00CB8D86
BF6707AA FD7E4F08 A1F70080 B9E6016B 8128004C B477817B BCF35106 BC60B06E
07A417FD 7979D262 B35465A6 1D3B70D1 36ACAFBD 7F91D5A0 CFB0EE91 B9D52C69
7CAF89ED F66A6A58 89EEF776 A03916CB 3663FB17 B7DBEBF8 1C54AF7F 293F3004
C15B08A8 C6965F1E 289DD724 BD40AF59 E90E44D5 7D590000 5C4BEA9D B5020301
0001
! The following commands declare a CA and configure a trusted point.
configure
crypto ca trustpoint myca
enrollment url http://xyz-ultra5
enrollment retry count 25
enrollment retry period 2
rsakeypair mykey
end
Uncommitted changes found, commit them? [yes]:yes
! The following command authenticates the CA to your router.
crypto ca authenticate myca
Serial Number :01
Subject Name :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Issued By :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Validity Start :07:00:00 UTC Tue Aug 19 2003
Validity End :07:00:00 UTC Wed Aug 19 2020
Fingerprint:58 71 FB 94 55 65 D4 64 38 91 2B 00 61 E9 F8 05
Do you accept this certificate?? [yes/no]:yes
! The following command requests certificates for all of your RSA key pairs.
crypto ca enroll myca
% Start certificate enrollment ...
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
% For security reasons your password will not be saved in the configuration.
% Please make a note of it.
Password:
Re-enter Password:
Fingerprint: 17D8B38D ED2BDF2E DF8ADBF7 A7DBE35A
! The following command displays information about your certificate and the CA certificate.
show crypto ca certificates
Trustpoint :myca
==========================================================
CA certificate
Serial Number :01
Subject Name :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Issued By :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Validity Start :07:00:00 UTC Tue Aug 19 2003
Validity End :07:00:00 UTC Wed Aug 19 2020
Router certificate
Key usage :General Purpose
Status :Available
Serial Number :6E
Subject Name :
unstructuredName=myrouter.mydomain.com,o=Cisco Systems
Issued By :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Validity Start :21:43:14 UTC Mon Sep 22 2003
Validity End :21:43:14 UTC Mon Sep 29 2003
CRL Distribution Point
ldap://coax-u10.cisco.com/CN=Root coax-u10 Certificate Manager,O=Cisco Systems
Certificate Authority Trust Pool Management
The trust pool feature is used to authenticate sessions, such as HTTPS, that occur between devices by using commonly recognized trusted agents called certificate authorities (CAs). This feature is enabled by default in the software to create a scheme to provision, store, and manage a pool of certificates from known CAs in a way similar to the services a browser provides for securing sessions. A special trusted point called a trust pool is designated, containing multiple known CA certificates from Cisco and possibly from other vendors. The trust pool consists of both built-in and downloaded CA certificates.
Implementing Certification Authority Interoperability provides details on Certificate Authority and trusted point.
CA Certificate Bundling in the Trust Pool
The router uses a built-in CA certificate bundle that is packaged into the asr9k-k9sec PIE. The bundle is contained in a special certificate store called a CA trust pool, which is updated automatically by Cisco. This trust pool is known by Cisco and other vendors. A CA certificate bundle can be in the following formats:
-
Privilege Management Infrastructure (PMI) certificates in Distinguished Encoding Rules (DER) binary format enveloped within a public-key cryptographic message syntax standard 7 (pkcs7).
-
A file containing concatenated X.509 certificates in Privacy Enhanced Mail (PEM) format with PEM headers.
Prerequisites for CA Trust Pool Management
Restrictions for CA trust pool management
Updating the CA Trustpool
The CA trustpool must be updated when the following conditions occur:
-
A certificate in the trustpool is due to expire or has been reissued.
-
The published CA certificate bundle contains additional trusted certificates that are needed by a given application.
-
The configuration has been corrupted.
The CA trustpool is considered as a single entity, As such, any update you perform will replace the entire trustpool.
Note |
A built-in certificate in the trustpool cannot be physically replaced. However, a built-in certificate is rendered inactive after an update if its X.509 subject-name attribute matches the certificate in the CA certificate bundle. |
Following are the methods available for updating the certificates in the trustpool:
-
Automatic update: A timer is established for the trustpool that matches the CA certificate with the earliest expiration time. If the timer is running and a bundle location is not configured and not explicitly disabled, syslog warnings should be issued at reasonable intervals to alert the admin that this trustpool policy option is not set. Automatic trustpool updates use the configured URL. When the CA trustpool expires, the policy is read, the bundle is loaded, and the PKI trustpool is replaced. If the automatic CA trustpool update encounters problems when initiating, then the following schedule is used to initiate the update until the download is successful: 20 days, 15 days, 10 days, 5 days, 4 days, 3 days, 2 days, 1 day, and then once every hour.
-
Manual update: Manually Update Certificates in Trust Pool provides details.
Manually Update Certificates in Trust Pool
The CA trust pool feature is enabled by default and uses the built-in CA certificate bundle in the trust pool, which receives automatic updates from Cisco. Perform this task to manually update certificates in the trust pool if they are not current, are corrupt, or if certain certificates need to be updated.
Procedure
Command or Action | Purpose | |
---|---|---|
Step 1 |
crypto ca trustpool import url clean Example:
|
(Optional) Manually removes all downloaded CA certificates. This command is run in the EXEC mode. |
Step 2 |
crypto ca trustpool import url url Example:
|
Specify the URL from which the CA trust pool certificate bundle must be downloaded. This manually imports (downloads) the CA certificate bundle into the CA trust pool to update or replace the existing CA certificate bundle. |
Step 3 |
show crypto ca trustpool policy Example:
|
Displays the CA trust pool certificates of the router in a verbose format. |
Configuring Optional Trustpool Policy Parameters
Procedure
Command or Action | Purpose | |
---|---|---|
Step 1 |
configure Example:
|
Enters mode. |
Step 2 |
crypto ca trustpool policy Example:
|
Enters ca-trustpool configuration mode where commands can be accessed to configure CA trustpool policy parameters. |
Step 3 |
cabundle url URL Example:
|
Specifies the URL from which the CA trustpool certificate bundle is downloaded. |
Step 4 |
crl optional Example:
|
Disables revocation checking when the trustpool policy is being used. By default, the router enforces a check of the revocation status of the certificate by querying the certificate revocation list (CRL). |
Step 5 |
description LINE Example:
|
Handling of CA Certificates appearing both in Trust Pool and Trust Point
There may be cases where a CA resides in both the trust pool and a trust point; for example, a trust point is using a CA and a CA bundle is downloaded later with this same CA inside. In this scenario, the CA in the trust point and its policy is considered, before the CA in the trust pool or trust pool policy to ensure that any current behavior is not altered when the trust pool feature is implemented on the router.
The policy indicates how the security appliance obtains the CA certificate and the authentication policies for user certificates issued by the CA.
Information About Implementing Certification Authority
Supported Standards for Certification Authority Interoperability
Cisco supports the following standards:
-
IKE—A hybrid protocol that implements Oakley and Skeme key exchanges inside the Internet Security Association Key Management Protocol (ISAKMP) framework. Although IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec security associations (SAs).
-
Public-Key Cryptography Standard #7 (PKCS #7)—A standard from RSA Data Security Inc. used to encrypt and sign certificate enrollment messages.
-
Public-Key Cryptography Standard #10 (PKCS #10)—A standard syntax from RSA Data Security Inc. for certificate requests.
-
RSA keys—RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adelman. RSA keys come in pairs: one public key and one private key.
-
SSL—Secure Socket Layer protocol.
-
X.509v3 certificates—Certificate support that allows the IPSec-protected network to scale by providing the equivalent of a digital ID card to each device. When two devices want to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or specify a shared key at each peer). These certificates are obtained from a CA. X.509 as part of the X.500 standard of the ITU.
Certification Authorities
Purpose of CAs
CAs are responsible for managing certificate requests and issuing certificates to participating IPSec network devices. These services provide centralized key management for the participating devices.
CAs simplify the administration of IPSec network devices. You can use a CA with a network containing multiple IPSec-compliant devices, such as routers.
Digital signatures, enabled by public key cryptography, provide a means of digitally authenticating devices and individual users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other. In simple terms, a signature is formed when data is encrypted with a user’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. The fact that the message could be decrypted using the sender’s public key indicates that the holder of the private key, the sender, must have created the message. This process relies on the receiver’s having a copy of the sender’s public key and knowing with a high degree of certainty that it does belong to the sender and not to someone pretending to be the sender.
Digital certificates provide the link. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity’s public key. The certificate is itself signed by a CA, a third party that is explicitly trusted by the receiver to validate identities and to create digital certificates.
To validate the signature of the CA, the receiver must first know the CA’s public key. Normally, this process is handled out-of-band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default. IKE, an essential component of IPSec, can use digital signatures to authenticate peer devices for scalability before setting up SAs.
Without digital signatures, a user must manually exchange either public keys or secrets between each pair of devices that use IPSec to protect communication between them. Without certificates, every new device added to the network requires a configuration change on every other device with which it communicates securely. With digital certificates, each device is enrolled with a CA. When two devices want to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new device is added to the network, a user simply enrolls that device with a CA, and none of the other devices needs modification. When the new device attempts an IPSec connection, certificates are automatically exchanged and the device can be authenticated.
CA Registration Authorities
Some CAs have a registration authority (RA) as part of their implementation. An RA is essentially a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.