Public Key Infrastructure (PKI) Troubleshooting
So far, this chapter has discussed IKE authentication using pre-shared keys. This section looks into some of the issues that you might run into when using digital certificates as a means of IKE authentication. The digital certificate is issued by a certificate authority (CA) server. The CA should issue the certificate at the time you install the device. It is not done for each IKE exchange. That is, after a device obtains a certificate, it does not need to contact the CA during the connection setup process unless you configure the device for Certificate Revocation List (CRL) Verification. This setup avoids the reliability problems associated with a centralized key server.
Configuration Steps
The Cisco Certificate Enrollment Protocol (CEP) manages the certificate life-cycle process. This protocol supports operations such as certificate enrollment, certificate revocation, and certificate access, allowing Cisco routers to participate within a public key infrastructure (PKI).
The general procedure has four steps as follows:
| Step 1. | The first step is to generate an RSA key pair on the router. The generated keys are saved in the private configuration in non-volatile random access memory (NVRAM). This private configuration is never displayed to the user or backed up to another device. A single CA must be defined for the router using its fully qualified domain name (FQDN) or IP address, the CA's HTTP common gateway interface (CGI) script path, and optionally, the certificate revocation list (CRL) query URL. |
| Step 2. | The second step of the general procedure is to retrieve the CA certificate. To authenticate the certificate of another device, the router must query the CA to obtain the CA certificate containing the CA public key. Because the router has no means of validating the CA certificate automatically, the key should be authenticated manually by contacting the CA administrator and comparing the fingerprints of the certificate. The validated certificate is stored in the configuration, and the public key from the CA certificate is added to the RSA public key chain. |
| Step 3. | The third step of the general procedure is to request that the CA generate a certificate for the key pair of the router by sending an enrollment request. A dialog is begun in which the user-defined certificate attributes are entered (a challenge password, a user addressable name, and optionally, the router serial number and IP addresses). The CA operator may cease to manually validate the request, and the fingerprints can be compared. |
| Step 4. | The fourth and last step of the general procedure is to request receipt of the certificate. Because there might be a significant delay, the certificate is retrieved asynchronously. |
Work through the following steps to enroll the certificate with the CA server:
| Step 1. | Define the hostname and domain-name. This is required, because the router assigns FQDN to the RSA key and Certificates. Router(config)# hostname Dhaka |
| Step 2. | Set the router clock. |
| Step 3. | Generate the RSA key pair. RSA key pair is used to sign and encrypt IKE key management messages. By default, a general purpose RSA key pair is generated. You can specify that usage keys be generated, which will generate a separate RSA key pair for signing and encryption. The syntax for generating the RSA key pair is as follows: crypto key generate rsa <general-keys> <usage-keys > |