Specifications

29-2
Cisco Security Appliance Command Line Configuration Guide
OL-6721-01
Chapter 29 Configuring Certificates
Public Key Cryptography
Obtaining the public key of a sender is normally handled out-of-band or through an operation done at
installation. For instance, most web browsers are configured with the root certificates of several CAs by
default. For VPN, the IKE protocol, a component of IPSec, can use digital signatures to authenticate peer
devices before setting up security associations.
Certificate Scalability
Without digital certificates, you must manually configure each IPSec peer for every peer with which it
communicates, and every new peer you add to a network would thus require a configuration change on
every peer with which you need it to communicate securely.
When you use digital certificates, each peer is enrolled with a CA. When two peers attempt to
communicate, they exchange certificates and digitally sign data to authenticate each other. When a new
peer is added to the network, you enroll that peer with a CA and none of the other peers need
modification. When the new peer attempts an IPSec connection, certificates are automatically exchanged
and the peer can be authenticated.
With a CA, a peer authenticates itself to the remote peer by sending a certificate to the remote peer and
performing some public key cryptography. Each peer sends its unique certificate which was issued by
the CA. This process works because each certificate encapsulates the public key for the associated peer
and each certificate is authenticated by the CA, and all participating peers recognize the CA as an
authenticating authority. This is called IKE with an RSA signature.
The peer can continue sending its certificate for multiple IPSec sessions, and to multiple IPSec peers,
until the certificate expires. When its certificate expires, the peer administrator must obtain a new one
from the CA.
CAs can also revoke certificates for peers that no longer participate in IPSec. Revoked certificates are
not recognized as valid by other peers. Revoked certificates are listed in a CRL, which each peer may
check before accepting a certificate from another peer.
Some CAs have an RA as part of their implementation. An RA is a server that acts as a proxy for the CA
so that CA functions can continue when the CA is unavailable.
About Key Pairs
Key pairs can be either RSA keys or DSA keys. Support for these two types of keys differs as follows.
• DSA keys cannot be used for SSH or SSL. To enable SSH or SSL access to a security appliance, you
must use RSA keys.
• SCEP enrollment is only supported for the certification of RSA keys. If you use DSA keys,
enrollment must be performed manually.
• For the purposes of generating keys, the maximum key modulus for RSA keys is 2048 while the
maximum key modulus for DSA keys is 1024. When you generate keys, the default size for either
key type is 1024.
• For signature operations, the supported maximum key sizes are 4096 bits for RSA keys and 1024
bits for DSA keys.
• You can generate a general purpose RSA key pair, used for both signing and encryption, or you can
generate separate RSA key pairs for each purpose. You can only generate a DSA key pair for signing
purposes.