About CAs and Digital Certificates
S e n d d o c u m e n t a t i o n c o m m e n t s t o m d s f e e d b a c k - d o c @ c i s c o . c o m
Purpose of CAs and Digital Certificates
CAs manage certificate requests and issue certificates to participating entities such as hosts, network
devices, or users. The CAs provide centralized key management for the participating entities.
Digital signatures, based on public key cryptography, digitally authenticate devices and individual users.
In public key cryptography, such as the RSA encryption system, each device or user has a key-pair
containing both a private key and a public key. The private key is kept secret and is known only to the
owning device or user only. However, the public key is known to everybody. The keys act as
complements. Anything encrypted with one of the keys can be decrypted with the other. A signature is
formed when data is encrypted with a sender's private key. The receiver verifies the signature by
decrypting the message with the sender's public key. This process relies on the receiver having a copy
of the sender's public key and knowing with a high degree of certainty that it really does belong to the
sender and not to someone pretending to be the sender.
Digital certificates link the digital signature to the sender. 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. The Internet Key Exchange
(IKE), an essential component of IPsec, can use digital signatures to scalably authenticate peer devices
before setting up security associations.
Trust Model, Trust Points, and Identity CAs
The trust model used in PKI support is hierarchical with multiple configurable trusted CAs. Each
participating entity is configured with a list of CAs to be trusted so that the peer's certificate obtained
during the security protocol exchanges can be verified, provided it has been issued by one of the locally
trusted CAs. To accomplish this, CA's self signed root certificate (or certificate chain for a subordinate
CA) is locally stored. The process of securely obtaining a trusted CA's root certificate (or the entire chain
in the case of a subordinate CA) and storing it locally is called CA authentication and is a mandatory
step in trusting a CA.
The information about a trusted CA that is locally configured is called the trust point and the CA itself
is called a trust point CA. This information consists of CA certificate (or certificate chain in case of a
subordinate CA) and the certificate revocation checking information.
The MDS switch can also enroll with a trust point to obtain an identity certificate (for example, for
IPsec/IKE). This trust point is called an identity CA.
RSA Key-Pairs and Identity Certificates
You can generate one or more RSA key-pairs and associate each RSA key-pair with a trust point CA
where the MDS switch intends to enroll to obtain an identity certificate. The MDS switch needs only one
identity per CA, which consists of one key-pair and one identity certificate per CA.
Cisco MDS SAN-OS allows you to generate RSA key-pairs with a configurable key size (or modulus).
The default key size is 512. You can also configure an RSA key-pair label. The default key label is the
switch fully qualified domain name (FQDN).
Cisco MDS 9000 Family CLI Configuration Guide
Configuring Certificate Authorities and Digital Certificates
OL-16184-01, Cisco MDS SAN-OS Release 3.x