Overview of CA Support
| Digital certificates bind an entity to a public key. This binding is necessary because when an IPSec peer receives a digital certificate, it needs to be absolutely certain the public key contained within is definitely tied to the peer it is trying to establish an IPSec session with. By having a trusted third party (the CA) sign the digital certificate, we create trust by association. We trust the third party to only sign digital certificates that it has checked to be true and valid. To obtain a digital certificate from a CA, we need to send our RSA public key to the CA as well as our own information. The CA verifies that the information we sent is valid and performs the necessary security checks on our information. Once the CA is certain the information we sent is valid, it places our information along with the public key in a certificate, signs the certificate, and identifies the signing method in the certificate itself. CA Standards Supported by Cisco IOS RoutersIOS-based routers support a number of certificate authorities:
IKEThe Cisco implementation of IKE uses the term ISAKMP synonymously with IKE. IKE is enabled globally by default for IOS-based routers, but if it were disabled, you would issue the following command to enable it: Router(config)# crypto isakmp enable PKCS #7The PKCS #7 standard defines the syntax for several kinds of cryptographically protected messages, including encrypted messages and messages with digital signatures. If a CA customer has multiple digital certificates that she needs created, she can encode all entity information in a bulk envelope called a Public Key Cryptography Standard (PKCS) #7. PKCS #10A single client seeking a digital certificate from a CA will place all his identify information as well as his public key into a form and encode the form using a special encoding method. The encoding method and resulting document is called a PKCS# 10 certificate request. This request is then sent to the CA, where it will eventually be signed by the CA and returned as a digital certificate. RSA KeysIn the Cisco IPSec implementation of RSA signatures, the RSA algorithm and keys play a vital part. As such, Cisco allows you to create RSA public/private keys directly on your IOS-based router. To create your keys, first be certain the date and time is valid on your router by issuing the show clock command from privilege mode. X.509v3 CertificatesWhen the CA receives the requester's PKCS #10 encoded certificate request, it validates the contents. If the CA determines the contents are indeed valid, it signs the data and returns a certificate to the requester in a certain format. The format the digital certificate is encoded in is called an X.509 version 3 certificate. CA InteroperabilityTo allow an IOS-based router to identify and use a CA, you must first determine the type of CA you will use, and then you must determine how you will enroll (obtain your digital certificate) from the CA. You can do so manually, or you can have most of the work done dynamically for you. SCEPCisco, along with VeriSign, created a dynamic method of CA enrollment called SCEP. With SCEP, you do not need to manually copy the PKCS #10 request and paste it in a window provided by the CA as well as other manual processes. How Does a Device Enroll with the CA?A device can enroll manually with a CA. That is, it can manually create the PKCS #10 request, manually copy it to the CA, manually request the digital certificate to be downloaded, and manually place the digital certificate in the device. But if at all possible, use the SCEP dynamic method of enrollment because it is much easier. Enrollment Process with the CATo obtain a digital certificate from the CA, you need to perform certain functions in a certain order. First, you need to declare which CA you will use, then you need to authenticate to the CA. When you authenticate the CA, you are obtaining the root CA's self-signed digital certificate. After you obtain the CA's root certificate, you can then request and obtain your own digital certificate. |
