|
|
Routers as Certificate AuthoritiesAs of IOS 12.3(4)T, Cisco routers can perform the function of a CA; RA functionality was added in a later IOS release. As a CA, routers can accept certificate requests using SCEP (which means that they have to run an HTTP server) and manual enrollment with cut-and-paste of the PKCS #10 information. The CA server feature was added mostly for small shops that wanted to use an existing router for certificate services instead of purchasing a stand-alone product. However, the Cisco CA server feature does have limitations; it isn't a full-blown CA product. Here are some of its restrictions:
Like getting a certificate on a router, there are many steps involved in setting up and managing a router acting as a CA:
Of the nine steps, note that only Steps 2 and 4 are required. The following sections will discuss these steps, and will show a simple example of a router configured as a CA.
Step 1: Generating and Exporting RSA Key InformationThe router, as a CA, needs an RSA key pair to create a signature on the root (its own) certificate and to validate it. You do not have to create the key pair manually, because the keys will be generated automatically during the configuration of the CA; however, if you use the automatic approach, you make the following concessions:
Caution If the router automatically generates the keys, the keys will be marked as nonexportable (unless using auto-archiving), making it impossible to move the CA from one router to another if the CA fails. Therefore, if you are not running IOS 12.3(11)T with auto-archiving, I highly recommend that you create the key pair manually and mark them as exportable. There are two basic ways of generating the RSA key pair on your CA router: manually or dynamically. With the latter, I recommend using the auto-archive option. The next two sections will discuss manual RSA keying and the "Step 2: Enabling the CA" section will discuss auto-archiving. Manual RSA Key Generation for the CATo manually generate your RSA keys for your router CA, use the following command: Router(config)# crypto key generate rsa general-keys label CA_name exportable The label you associate with the keys must match the name of the CA trustpoint (the router). Also, be sure to specify the keys as exportable. Note The CA_name key label should not exceed 13 characters, because this is used as the CA's name and this name, when the router is a CA, has that restriction. Next, you need to export your keys using the following command: Router(config)# crypto key export rsa CA_name pem {terminal | url URL} {des | 3des} passphrase For the key label, you must specify the name of the CA from the crypto key generate rsa command. The pem parameter specifies that this is a backup process. Two files will be created: one for the public key and one for the private. The terminal/url parameters specify where to back it up; most commonly it is first backed up to NVRAM or Flash memory for simplicity's sake and then moved to a more secure location. You must tell the router which encryption algorithm to use to encrypt the two files, and the passphrase used for the encryption process. Caution Don't forget what you configured as the passphrase when exporting the CA's RSA key pair; otherwise you'll never be able to re-import your keys to restore your router CA if it fails! If this happens, you'll have to create new keys and a new root certificate, install the root certificate on all devices, and then create identity certificates for each device and install these. I definitely would not want to re-implement a certificate solution over something as simple as forgetting the passphrase for the PEM files! To import your RSA keys into a router, use the following command: Router(config)# crypto key import rsa CA_name pem {terminal | url URL} {des | 3des} [exportable] passphrase Tip Here's a trick I learned to protect the CA's keys. First, export the keys, then reimport them but use a different key label; when importing them, don't specify them as exportable. If you use this process, the keys you imported are re-imported but can no longer be exported. Then place the keys you exported in a safe place. This way, no one who has access to the router will be able to export the keys and use them to create a rogue CA. You can also use the crypto key export rsa and crypto key import rsa commands in this fashion for non-CA routers, which will prevent anyone with a level-15 access from re-exporting the keys. Example 16-28 illustrates this process. The numbered references to the right of certain commands are explained below the example. Example 16-28. Protecting the CA's Keysrouterca(config)# crypto key generate rsa general-keys (1) label routerca exportable The name for the keys will be: routerca Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys ...[OK] routerca(config)# crypto key export rsa routerca pem (2) url nvram:routerca 3des cisco123 % Key name: routerca Usage: General Purpose Key Exporting public key... Destination filename [routerca.pub]? Writing file to nvram:routerca.pub Exporting private key... Destination filename [routerca.prv]? Writing file to nvram:routerca.prv routerca(config)# crypto key import rsa routerca2 pem (3) url nvram:routerca cisco123 % Importing public key or certificate PEM file... Source filename [routerca.pub]? Reading file from nvram:routerca.pub % Importing private key PEM file... Source filename [routerca.prv]? Reading file from nvram:routerca.prv% Key pair import succeeded. routerca(config)# exit routerca# show crypto key mypubkey rsa (4) % Key pair was generated at: 20:30:59 EDT Mar 18 2005 Key name: routerca Usage: General Purpose Key Key is exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 Here's an explanation of the numbered references in Example 16-28:
Step 2: Enabling the CAWhether you're using manually generated RSA keys or auto archiving, you must enable the CA process on the router. The next two sections describe this process. Using Manual RSA KeysIf you have defined your RSA keys manually, use the following process to bring up the CA and use the configured key pair: Router(config)# ip http server Router(config)# crypto pki server CA_name Router(cs-server)# issuer-name CA_string Router(cs-server)# lifetime ca-certificate time_in_days Router(cs-server)# database url root_URL Router(cs-server)# no shutdown Router(cs-server)# exit The ip http server command allows you to use SCEP for end-clients to obtain certificates. The crypto pki server command creates the CA process on the router. It is important to use the RSA key pair label you specified (when generating the RSA key pair) as the CA name; this tells the router which key pair label to use for signing and validating the self-signed certificate. The issuer-name command specifies the name that will appear on the CA's certificate for the Common Name (CN) and on all identity certificates under the Issuer section. If this is omitted, the CA_name parameter is used from the crypto pki server command. Once the router CA is brought up initially and the CA certificate created, you cannot change this value without deleting the CA and re-adding it. The CA_string parameter specifies what should appear in the X.509 CA certificate fields. An example CA_string would look something like this: issuer-name CN = routerca.cisco.com, L = San Jose, C = USA. The lifetime ca-certificate command specifies the lifetime of the CA's certificate. The time is specified in days and if you omit it, the time defaults to three years. The lifetime can range from 11,825 days. Once you create the CA's certificate you cannot change its lifetime length without deleting and re-adding the router CA process (which invalidates any currently created identity certificates). The database url command specifies the location where all database entries (certificate information) for the router CA and its clients will be stored. The default location, if this command is not configured, is in NVRAM. If the router needs to manage a large number of certificates that contain detailed information, I would recommend placing this on a remote device, such as an SCP server, or a large Flash image, like a PCMCIA Flash card. TFTP or FTP will work for external storage, but it lacks a real protection mechanism (confidentiality, authentication, except for FTP, and data integrity). In this case, you might want to use a transport IPsec session (point-to-point) between the router CA and the storage server. If you change the value for the database url command, you'll need to move the current database contents from the original location to the new location. Tip Assuming that your router CA will handle only a small number of certificates, you might want to put these in Flash memory on the router (database url flash:) or on a PCMCIA Flash card (databse url slotX:, where X is the slot number). For a very large number of identity certificates, I would recommend storing them on an SCP server first, or if this is not available, a TFTP server where the connection between the router CA and the TFTP server is protected using a transport IPsec session and is firewalled. The no shutdown command enables the router CA process and will generate the CA's certificate when initially performed. If the CA_name doesn't match an existing key pair, the router will generate an RSA key pair automatically using 1,024-bit keys, as shown in Example 16-29. Example 16-29. Starting the CA with no Specified RSA Key Pairrouterca(config)# crypto pki server routerca routerca(cs-server)# no shutdown % Generating 1024 bit RSA keys ...[OK] % Ready to generate the CA certificate. % Some server settings cannot be changed after CA certificate generation. Are you sure you want to do this? [yes/no]: yes % Exporting Certificate Server signing certificate and keys... % Please enter a passphrase to protect the private key. Password: cisco123 % Certificate Server enabled. Caution If you use the approach shown in Example 16-29, the keys cannot be exported; so I highly recommend you do not do this! If you make this mistake, delete the CA (see the "Step 8: Removing a CA" section later) and then either use the manual key creation approach or auto-archiving (see the next section). The CA's self-signed certificate is automatically created and can be viewed with the show crypto ca certificates command shown in Example 16-30. Notice that the issuer and subject CN names are the same. Example 16-30. Viewing the CA's Certificaterouterca# show crypto ca certificates CA Certificate Status: Available Certificate Serial Number: 01 Certificate Usage: Signature Issuer: cn=routerca2 Subject: cn=routerca2 Validity Date: start date: 01:32:12 EDT Mar 19 2005 end date: 01:32:12 EDT Mar 18 2008 Associated Trustpoints: routerca2 If you configured the database url command and the URL is not reachable when the router CA is creating its root certificate, you'll see the output in Example 16-31. You'll need to fix the problem and attempt the no shutdown command again. Example 16-31. CA Database Not Located in NVRAMrouterca(config)# crypto pki server routerca routerca(cs-server)# database url ftp://192.1.1.77 routerca(cs-server)# no shutdown % Once you start the server, you can no longer change some of % the configuration. Are you sure you want to do this? [yes/no]: yes Translating "192.1.1.77" % Failed to generate CA certificate - 0xFFFFFFFF % The Certificate Server has been disabled. Using Auto-ArchivingIn IOS 12.3(11)T, Cisco introduced the auto-archiving feature. This process is used to eliminate the complicated process of creating and exporting a key pair manually and then calling the CA service by the same name used by the key pair. When using auto-archiving, the router automatically will create an RSA key pair (1,024 bits in length) and export the keying information into a PKCS #12 or PEM file in NVRAM. To configure auto-archiving, use these commands: Router(config)# ip http server Router(config)# crypto pki server CA_name Router(cs-server)# issuer-name CA_string Router(cs-server)# lifetime ca-certificate time_in_days Router(cs-server)# database url root_URL Router(cs-server)# database archive {pkcs12 | pem} [password passphrase] Router(cs-server)# no shutdown Router(cs-server)# exit As with the manual process, you must enable the HTTP server for SCEP and then specify the trustpoint you're creating. You can generate an RSA key pair manually and specify the key label for the CA_name; this is necessary only if you don't want to use the default of 1,024 bits for the keys, but another value. If this is necessary, be sure to create the keys as exportable with the crypto key generate rsa command. The issuer-name and lifetime ca-certificate commands were discussed in the last section. Within the CA configuration, the database archive command specifies that auto-archiving will be used. The two file formats you have to choose from are PKCS #12 or PEM. If you don't specify the passphrase to encrypt the exported information, you'll be prompted for this. Execute the no shutdown command to generate the keying information (if the keys don't already exist) and the CA's certificate with the name of the certificate specified in crypto pki server command. Note If you don't execute the database archive command, auto-archiving still will take place, where the default file format will be PKCS #12you'll be prompted for the encryption password. The auto-archiving process occurs only once, when the CA is initially started. When done, you should back up the files in NVRAM that the auto-archiving process created! Example 16-32 illustrates bringing up a CA with auto-archiving. If I had omitted the database archive command before bringing up the database (no shutdown), auto-archiving still would take place. In this example, I had not pre-created any RSA keys. After the CA came up, looking in NVRAM revealed three new files: routerca.ser, routerca.crl, and routerca.p12. The first file (.ser), the enrollment database, contains identity certificates issued by the router CA; the second file (.crl) contains the CRL; and the last file (.p12 or .pem) contains the encrypted public/private keys. You should copy all three of these files to a secure location. Example 16-32. Bringing up a CA with Auto-Archivingrouterca(config)# crypto pki server routerca routerca(cs-server)# database archive pkcs12 password cisco123 routerca(cs-server)# no shutdown % Generating 1024 bit RSA keys ...[OK] % Ready to generate the CA certificate. % Some server settings cannot be changed after CA certificate generation. Are you sure you want to do this? [yes/no]: yes % Exporting Certificate Server signing certificate and keys... % Certificate Server enabled. routerca(cs-server)# end routerca# dir nvram: Directory of nvram:/ Caution Once the CA is brought up and the CA certificate created, you cannot change anything on the CA certificate unless you completely delete the CA on the router. This also is true of some CA commands discussed in the next section! Therefore, because this would affect any identity certificates the CA generated, you would have to start from scratch if you deleted the CA and changed its certificated information. Step 3: Defining Additional CA ParametersOptionally, you can define parameters for the CA that affects its functionality. Here are the commands to define these parameters: Router(config)# crypto pki server CA_name Router(cs-server)# database level {minimal | names | complete} Router(cs-server)# database username username password password Router(cs-server)# lifetime certificate time_in_days Router(cs-server)# lifetime crl time_in_hours Router(cs-server)# lifetime enrollment-request time_in_hours Router(cs-server)# cdp-url URL_of_CRL Router(cs-server)# grant {none | auto | ra-auto} Router(cs-server)# [no] shutdown Router(cs-server)# exit The database level command specifies what kind of information is stored in the certificate enrollment database for identity certificates. Your options are as follows:
If you don't configure this command, the default is minimal. The database username command allows you to restrict access to the database file (CA_name.ser). By specifying a username and an associated password, only the specified users with the specified passwords can access the enrollment database to add/revoke identity certificates. If you have different types of administrators accessing the CAone to manage the router and one to manage certificate servicesyou should configure this command to lock out the router management people from being able to manipulate the ".ser" file. The lifetime certificate command specifies the lifetime, in days, of any generated identity certificate. If you omit this parameter, it defaults to one year. The lifetime can range from 11,825 days. If you change this value, the new lifetime will affect only newly created identity certificates. The lifetime crl command specifies the valid lifetime length, in hours, of a CRL the CA generates. The default lifetime is one week (168 hours), but can be extended to 336 hours. This value affects any newly created CRLs by the router CA (the CRL is stored in the CA_name.crl file). The lifetime enrollment-request command specifies how long, in hours, an open enrollment request is allowed to stay in the enrollment database. This value affects identity certificates that are not automatically created by the CA when the client is using SCEP. The default lifetime is one week, but it can be extended to 1,000 hours. The cdp-url command specifies the CRL distribution point (CDP) to be used in identity certificates issued by the CA. When this doesn't appear on a certificate, the client will use SCEP to directly retrieve the CRL from the CA (stored in the CA_name.crl file). This command allows you to hardcode the CRL location on any newly issued identity certificate, offloading the CRL process to a different device. However, if the remote CRL is not reachable, a client always can use SCEP to obtain the CRL directly from the CA. Because of possible client constrictions, it is highly recommended to put the CRL on an HTTP server instead of another type. In this case, the cdp-url command would look something like this: Router(cs-server)# cdp-url http://IP_address_or_name_of_CRL_server/ directory_location/CA_name.crl When executing this command, any newly issued identity certificates will have this listed as its CRL Distribution Point on the identity certificateexisting certificates either will have the old URL or none at all, depending on the previous CDP configuration on the router CA. The grant command specifies whether manual authorization of a requested identity certificate is required (none) or that the router CA automatically will grant an identity certificate request (auto). The default is none. The third parameter is ra-auto, which allows auto-enrollment requests from an RA. For this option to work, the RA's X.509 certificate must include the following: "cn=ioscs RA" or "ou=ioscs RA." Caution If your router CA is connected to the Internet, I highly recommend that you do not set the grant command to auto or auto-ra, since this allows almost anybody to request a certificate. Even if you use a pre-shared key for this process, it is possible for an authorized person to keep on requesting certificates for the same device, wasting storage resources on the router or remote server. If you use the grant auto command, I recommend setting a password lifetime that is very shortthis way, the client requests a certificate via SCEP using the password, then this password expires shortly and no one else can use the same password. See the next section, "Step 4: Handling Enrollment Requests" for more information on the crypto pki server password generate command. The shutdown command disables the router CA without removing its configuration commands and certificate information. To re-enable it, use no shutdown. Once the CA is up, you can verify its configuration and operation with the show crypto pki server command, shown in Example 16-33. In this example, the CA is enabled and the CA's certificate is valid until 2008. The next CRL will be generated on March 28, 2005 and the certificate database is set to a minimal level and is stored in NVRAM. Example 16-33. Viewing the Status of the Router CArouterca# show crypto pki server
Certificate Server routerca:
Status: enabled
Issuer name: CN=routerca
CA cert fingerprint: DC978D21 375DA8DE 2F28FF16 B45C2103
Granting mode is: manual
Last certificate issued serial number: 0x1
CA certificate expiration timer: 11:54:32 EDT Mar 20 2008
CRL NextUpdate timer: 11:54:33 EDT Mar 28 2005
Current storage dir: nvram:
Database Level: Minimum - no cert data written to storage
When you reboot your router, if you see either of the following two messages, this probably indicates a temporary problem where the router hasn't fully parsed the startup configuration file to configure the CA process:
Once the router has loaded and executed its configuration file, use the show crypto pki server command to verify its status. Step 4: Handling Enrollment RequestsNow that you have your router CA up and operational, it's ready to handle enrollment requests for identity certificates. The management commands that handle the enrollment process are not Configuration mode commands, but Privilege EXEC commands: Router# crypto pki server CA_name info requests Router# crypto pki server CA_name remove {all | reqID} Router# crypto pki server CA_name grant {all | reqID} Router# crypto pki server CA_name reject {all | reqID} Router# crypto pki server CA_name password generate [minutes] Router# crypto pki server CA_name request pkcs10 {URL | terminal} [pem] The following subsections will discuss these commands. Viewing Enrollment RequestsTo view identity certificate enrollment requests, use the crypto pki server CA_name info requests command. Example 16-34 illustrates the use of this command, where one certificate request (reqID #1) is pending approval/authorization. Table 16-2 lists the states a certificate request can be in. Example 16-34. Listing Certificate Requests in the Enrollment Databaserouterca# crypto pki server routerca info requests Enrollment Request Database: Subordinate CA certificate requests: ReqID State Fingerprint SubjectName --------------------------------------------------------------
When a user either sends a certificate request via SCEP or a router administrator enters the user's request manually on the router CA, the enrollment request is added to the router CA's enrollment database in an initial state. Each enrollment request is assigned a unique request ID (ReqID) number. If using SCEP, the end user will receive a pending reply, if grant none has been configured for the CA. If grant auto is configured and the correct password is supplied to the user, the user will see a granted reply; otherwise, the certificate request is denied. If the router CA is configured with grant none, an administrator will need to log in to the CA and either approve the certificate request (granted) or deny it (denied). Note All SCEP enrollment requests are treated as new certificate enrollment requests, even if the requestor specifies the same subject name or public key pair as what was in a previous requestin other words, the router CA doesn't perform an extended database lookup the router CA ignores any the old request by the same requestor. Tip You can use the debug crypto pki server command to troubleshoot enrollment problems for certificate requests using SCEP. Removing Requests from the Enrollment DatabaseTo remove an enrollment request from the CA's database, use the crypto pki server CA_name remove command. If you specify the all parameter, all enrollment requests are removed; in most cases, you'll use the reqID of the request to remove a single request. Please note that this is not the same as rejecting a request. Also, if you have configured a username/password for the CA database (database username command), you'll be prompted for this before the command can be executed successfully. Tip Typically, when requesting clients submit their certificate request, the CA places the request in the enrollment database in a pending state. Normally, these clients will recheck the CA for a limited time to see if the request was granted, at which point they give up. On a Cisco router as a client, you can execute the crypto ca enroll command to resend the request and retrieve the newly created identity certificate. However, on other clients, a new request sometimes is generated, leaving the old request in the database. Using the crypto pki server remove command allows you to remove the old entry. Granting Enrollment RequestsTo grant a pending enrollment request, use the crypto pki server CA_name grant command; specifying the all parameter grants all pending certificate requests while specifying the reqID of the single request only grants that specific request. Also, if you've configured a username/password for the CA database (database username command), you'll be prompted for this before the command can be executed successfully. The actual identity certificate created for the requesting device is then stored in the location specified by the database url command. Two files will be created using this nomenclature:
The .crt file contains the actual identity certificate and the .cnm file contains a brief description of the certificate: the subject name, host name, and the expiration date. Once a certificate is downloaded from the CA, the router CA removes the enrollment entry from its database. Certificate requests not granted within the lifetime value specified in the lifetime enrollment-request command will expire and will be removed from the enrollment database automatically. Rejecting Certificate RequestsIf a certificate request is not valid, you can reject it with the crypto pki server CA_name reject command. In most instances, you'll only reject a specific request by adding the reqID to the command. Also, if you have configured a username/password for the CA database (database username command), you'll be prompted for this before the command can be executed. Controlling Certificate Requests with PasswordsWhen using SCEP, as mentioned earlier, I recommend password-protecting certificate requests. To create a password for certificate requests, use the crypto pki server CA_name password generate command. This causes a random password to be created that is used to validate SCEP requests (the challenge password). Also, if you have configured a username/ password for the CA database (database username command), you'll be prompted for this before the command can be executed successfully. By default, the generated password is valid for 60 minutes unless you specify otherwise (11,440 minutes). If you create a password and then use the command to create another password, the first one is removed and replaced with the second one. Example 16-35 illustrates the use of this command: Example 16-35. Creating a Challenge Password for SCEProuterca# crypto pki server routerca password generate
% New password is B71725E963B49FAB, valid for 60 minutes
Manually Entering a Certificate EnrollmentIf the client doesn't support SCEP, you can perform a manual enrollment process, creating a PKCS #10 file on the client and then importing it into the router CA. To import the client's PKCS #10 file on the router CA, use the crypto pki server CA_name request pkcs10 command. You can specify either a URL with the location of the requesting client's PKCS #10 file or specify the terminal parameter and cut-and-paste the PKCS #10 file into the router CA. If you specify the pem (privacy-enhanced mail) option, PEM headers are added automatically to the certificate when it is granted. Example 16-36 illustrates the process of pulling in a PKCS #10 file (.req) extension and granting request, and generating the certificate (.crt file). Example 16-36. Manually Importing a PKCS #10 File and Granting a Certificaterouterca# crypto pki server mycs request pkcs10 tftp://192.1.1.77/r3620 % Retrieving Base64 encoded or PEM formatted PKCS10 enrollment request... Reading file from tftp://192.1.1.77/router5.req Loading router5.req from 192.1.1.77 (via Ethernet0/0): ! [OK - 582 bytes] % Enrollment request pending, reqId=1 routerca# crypto pki server mycs grant 1 % Writing out the granted certificate... !Writing file to tftp://192.1.1.77/router5.crt! Step 5: Revoking Identity CertificatesIf an identity certificate is no longer being used, has been compromised, or if there has been a change of policy, you can revoke it with the following command: Router# crypto pki server CA_name revoke certificate_serial_# The certificate serial number is the same as the reqID number in decimal; you can enter the serial number in hexadecimal by preceding the hexadecimal number by "0x." Also, if you have configured a username/password for the CA database (database username command), you'll be prompted for this before the command can be executed. A new CRL is created whenever the previous CRL is revoked or updated (a new revoked certificate is added); however, it is not issued to the URL in the cdp-url command until the time period in the lifetime-crl command is reached. To see the list of revoked certificates, and the CRL, use the following command: Router# crypto pki server CA_name info crl Example 16-37 illustrates the use of this command. In this example, there is only one revoked certificate. Example 16-37. Viewing the Router CA's CRLrouterca# crypto pki server routerca info crl Certificate Revocation List: Issuer: cn=routerca This Update: 20:16:34 EDT Mar 21 2005 Next Update: 20:16:34 EDT Mar 28 2005 Number of CRL entries: 1 CRL size: 240 bytes Revoked Certificates: Serial Number: 0x02 Revocation Date: 20:16:34 EDT Mar 21 2005 Tip When you revoke a certificate, remember to delete the corresponding .cnm and .crt files for the serial number, since the crypto pki server CA_name revoke command doesn't perform this task for you. Step 6: Configuring a Server to Run in RA ModeOnce you have configured a router as a CA, you might want to consider configuring another router as an RA and then delegate the enrollment request process to that device. The RA is responsible for recording or verifying certificate information that the CA will need to issue a certificate, and to validate existing certificates. Please note that the RA cannot itself generate new certificates; only the CA can do this. By offloading much of the enrollment process to the RA, in addition to validating certificates, the only two tasks the CA has to perform are to sign certificates and maintain the CRL. RA Configuration and OperationYou can configure a router to run in RA mode; however, the limitation of this process is that the CA must also be an IOS router. When operating as an RA and when the RA receives an enrollment request (manual or SCEP), the RA can grant or reject the request based on policy information. If the request is granted, however, the certificate request is forwarded to the CA, which will generate the identity certificate and return it to the RA; the requestor can then recontact the RA to obtain its new identity certificate. Once you've set up the CA, setting up an RA is a two-step process: (1) enroll with the CA and (2) define the RA. To enroll with the CA, you would perform the steps that you normally would to obtain an identity certificate. You would define a trustpoint; however, you won't actually download the CA certificate with the crypto ca authenticate command and an identity certificate with the crypto ca enroll command. Instead, you'll set up the router as an RA, which will perform this process automatically: Router(config)# crypto key generate rsa Router(config)# crypto {ca | pki} trustpoint CA_name Router(ca-trustpoint)# enrollment url CA_URL Router(ca-trustpoint)# subject-name X.500_name Router(ca-trustpoint)# exit Router(config)# crypto pki server RA_name Router(cs-server)# mode ra Router(cs-server)# grant ra-auto Router(cs-server)# no shutdown The subject-name command must include either "cn=ioscs RA" or "ou=ioscs RA" for the CA to recognize it as an RA. Also, when creating the RA server with the crypto pki server command, you must enter the name of the RA, not the CA. The grant ra-auto command allows automatic approval of SCEP certificate requests. As mentioned in the "Step 3: Defining Additional CA Parameters" section earlier, I highly recommend not using this option but to manually approve certificates (grant none), which is the default. Once the RA has its certificate from the CA and is operational, it can view and handle certificate requests sent to it using the crypto pki server CA_name info requests and crypto pki server CA_name grant reqID commands. Please note that the RA cannot revoke certificates: only the CA can perform that task. Example of Setting Up an RAAs you can see from the previous section, setting up an RA is a simple process. Example 16-38 illustrates the setup of an RA. When the no shutdown command is executed, an RSA key pair is generated automatically, the CA certificate is downloaded, the RA requests an identity certificate, and the CA grants it (automatically with a SCEP challenge password, in this instance). The show crypto pki server command shows that the router is running in RA server mode. Example 16-38. Setting Up an RA RouterRouterraconfig)# crypto pki trustpoint routerca Routerra(ca-trustpoint)# enrollment url http://192.1.1.40 Routerra(ca-trustpoint)# subject-name cn=routerfa, ou=ioscs RA, o=cisco, c=us Routerra(ca-trustpoint)# exit Routerra(config)# crypto pki server routerra Routerra(cs-server)# mode ra Routerra(cs-server)# no shutdown % Generating 1024 bit RSA keys ...[OK] Certificate has the following attributes: Fingerprint MD5: 32661452 0DDA3CE5 8723B469 09AB9E85 Fingerprint SHA1: 9785BBCD 6C67D27C C950E8D0 718C7A14 C0FE9C38 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. % Ready to request the CA certificate. % Some server settings cannot be changed after the CA certificate has been requested. Are you sure you want to do this? [yes/no]: yes % % 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: cisco123 Re-enter password: cisco123 % The subject name in the certificate will include: cn=routerca, ou=ioscs RA, o=cisco, c=us % The subject name in the certificate will include: routerra.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto pki certificate' command will also show the fingerprint. % Enrollment in progress... Mar 22 22:32:40.197: CRYPTO_PKI: Certificate Request Fingerprint MD5: 82B41A76 AF4EC87D AAF093CD 41ACDB20 Mar 22 22:32:40.201: CRYPTO_PKI: Certificate Request Fingerprint SHA1: 897CDF40 C6563EAA 0FED05F7 0115FD3A F137CADF Mar 22 22:34:00.366: %PKI-6-CERTRET: Certificate received from Certificate Authority routerra(cs-server)# end routerra# show crypto pki server Certificate Server routerfa: Status: enabled Issuer name: CN=routerca CA cert fingerprint: 32661452 0DDA3CE5 8723B469 09AB9E92 Server configured in RA mode RA cert fingerprint: C65F5724 0E63B3CC BE7AE016 BE0D34D1 Granting mode is: manual Current storage dir: nvram: Database Level: Minimum - no cert data written to storage Step 7: Backing up a CAOnce you've set up your CA, you should back up its files. In Example 16-39, I chose the option of storing files in the router's NVRAM. Example 16-39. CA Files to Back Uprouterca# dir nvram: Directory of nvram:/ Here are the files you should regularly back up:
Step 8: Restoring a CAIf your CA configuration becomes corrupted or the CA itself dies, you can restore the CA from the files you backed up on the previous section (you should be doing this religiously!). Caution Remember that each time your router CA generates an identity certificate, you'll need to back up the corresponding .crt and .cnm files! And a good backup strategy is to make sure that these files are at a physically different location than the current CA, just in case there is a catastrophic disaster and the location of where the CA is situated is completely destroyed by a fire or by some other disaster. If the .ser, .crl, .p12/.pem, or .cer files are lost, you will not be able to restore the CA. Likewise, you need the password that encrypted the .p12/.pem file! The first step is to take the saved running configuration of the failed CA and paste in only the commands that are not CA- and certificate-related, such as IP addressing, routing, security, and so on. Next, you need to copy in the files you backed up in "Step 7: Backing up a CA" (with the exception of the running configuration). Example 16-40 illustrates the copying process, where I'm restoring the .cer, the .crl, the .ser, and each identity certificate (I only listed the first one, serial number 2). Example 16-40. Restoring the Files to a New CArouterca# copy tftp://192.1.1.77/routerca#6101CA.cer nvram: Please note that in this example, originally I had stored the identity certificate files (.crt and .cnm) in NVRAM; in most cases they'd be restored to Flash memory or not on the router at allthe files are located external to the router. Once you have copied the files into NVRAM, you now need to import your RSA key pair, as shown in Example 16-41. Remember that you must know the encryption key ("cisco123" in this example) to import the keys. Example 16-41. Importing the Saved RSA Key Pairrouterca# configure terminal routerca(config)# crypto pki import routerca pkcs12 tftp://192.1.1.77/routerca.p12 cisco123 After importing the key pair, you can configure the CA and bring it up, as shown in Example 16-42. Please note that before bringing up the CA (no shutdown), enter all of the CA's configuration commands from the backed-up CA configuration. Remember that some things cannot be changed with the CA after you bring it up. If you make this mistake, remove the CA (see the next section), reimport the keys, and redo the CA configuration. Use the show crypto pki server command to verify the operational status of the CA, its configuration, and its certificate signature. As you can see from this process, restoring a CA is not hard; however, it will be impossible if you don't back up the correct files on the CA! Example 16-42. Configuring and Bringing Up the New CArouterca(config)# crypto pki server routerca routerca(config)# ! Enter the other CA configuration commands before bringing ! up the CA! routerca(cs-server)# no shutdown % Certificate Server enabled. routerca(cs-server)# end routerca# show crypto pki server Certificate Server routerca: Status: enabled Issuer name: CN=routerca CA cert fingerprint: DC978D21 375DA8DE 2F28FF16 B45C2103 Granting mode is: manual Last certificate issued serial number: 0x4 CA certificate expiration timer: 11:54:32 EDT Mar 20 2008 CRL NextUpdate timer: 11:21:10 EDT Mar 29 2005 Current storage dir: nvram: Database Level: Minimum - no cert data written to storage Step 9: Removing CA ServicesNormally, you won't delete a CA (remove its services) unless you want to remove it from service or replace it with another system. When deleting the CA services on a router, the CA trustpoint, the CA certificate, and the CA RSA key pair are automatically deleted. To perform this process, use this command: Router(config)# no crypto pki server CA_name Example 16-43 shows an example of removing the CA services on a router. You'll be prompted to verify that you really want to do this and acknowledge that the trustpoint configuration, the CA certificate, and the RSA key pair will be deleted. Example 16-43. Removing CA Services on a Routerrouterca(config)# no crypto pki server routerca % This will stop the Certificate Server process and delete the server configuration Are you sure you want to do this? [yes/no]: yes % Do you also want to remove the associated trustpoint and signing certificate and key? [yes/no]: yes No enrollment sessions are currently active. % Certificate Server Process stopped Caution If you'll be moving CA services to another router, be sure that you follow the guidelines in "Step 7: Backing up a CA" before removing the CA from your router! Otherwise you'll have to start from scratch and re-create all your devices' identity certificates, which is not a task I would envy.  |
|
|
output omitted
% Key pair was generated at: 20:31:02 EDT Mar 18 2005
Key name: routerca.server
Usage: Encryption Key
Key is not exportable.
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B637AD