Chapter 18: Fundamentals of the Public Key

Infrastructure
I. Public Key Infrastructure
1. Public and Private Key Pairs
1.
2.
3.
4.
5.

Key pair works as team.

Typical have a public key and a private key; private key is only known by the server
If public key is used to encrypt, only the private key can decrypt and vice versa
Known as Public Key Cryptography or Asymmetric Key Cryptography
Used for VPN authentication and a precursor to symmetric ciphers used for bulk
traffic
6. Digital Signatures
7. Other uses
a. RSA Named after Rivest, Shamir, and Adleman, who created the algorithm.
The primary use of this asymmetrical algorithm today is for authentication. It is
also known as public key cryptography standard (PKCS) #1. The key length
may be from 512 to 2048, and a minimum size for good security is at least 1024.
Regarding security, bigger is better (more secure)
b. DH Diffie-Hellman key exchange protocol. DH is an asymmetrical algorithm
that allows two devices to negotiate and establish shared secret keying material
(keys) over an untrusted network. The interesting thing about DH is that
although the algorithm itself is asymmetrical, the keys generated by the
exchange are symmetrical keys that can then be used with symmetrical
algorithms such as Triple Digital Encryption Standard (3DES) and Advanced
Encryption Standard (AES).
c. ElGamal (second character is an L) This asymmetrical encryption system is
based on the DH exchange
d. DSA Digital Signature Algorithm was developed by the U.S. National
Security Agency
e. ECC Elliptic Curve Cryptography
8. Require more CPU
9. 512 to 4096 bits (minimum should be 1024) anything less than 1024 is considered
unreliable and not as secure as a longer key
10. RSA is commonly used asymmetrical algorithm (RSA digital signatures)

2. RSA Algorithm, the Keys, and Digital Certifications

1. Keys are the secrets that allow cryptography to provide confidentiality

3. Who Has Keys and a Digital Certificate?

1. RSA digital signatures, each party has a public-private key pair, generated by each
termination point and enrolled with a certificate authority (CA) and digitally signed
by that CA. Used by termination points to authenticate each other

4. How Two Parties Exchange Public Keys

1. Each termination point sends a copy of their digital certificates and verify the
authenticity of the digital signature against the CA using the CA's public key
2. Now that each party has each others public keys, they can authentication each other
3. Usually used for a VPN

5. Creating a Digital Signature

1. Bob takes some data, generates a hash and encrypts the hash using Bob's private key.
The hash is attached to the packet and sent to Lois for authentication of Bob. Lois
can use the public key to decrypt the hash, sets the decrypted hash aside and runs the
hashing algorithm against the data to verify that it's correct. Bob has now been
authenticated

6. Certificate Authorities
1. Certificate authority is a computer or entity that creates and issues digital
certificates.
2. Inside the Digital Certificate
a. Information about the identity of the device such as IP FQDN and public key of
the device
b. CA takes all the info including the public key generated by the device and
generates a digital certificates CA assigns a serial number to and signs the
certificate with its own digital certificate (CAs signature).
c. Also includes validity dates for the certificate, expiration, possibly revocation
details.
d. Also information about the CA, including a URL to check the certificate against
the CA.
e. Most web browsers have a huge list of common CAs.
f. Could create your own CA server, but no one would trust it you would use it
internally only

7. Root and Identity Certificates

1. Digital certificate can be thought of as an electronic identification document
2. Includes the name of the person or organization, their address, public key of that
person or device
3. Root certificate Identifies a CA
4. Identity certificate Identifies device or server of other devices that want to
participate in PKI (public key infrastructure)

8. Root Certificate
1. Contains public key of CA server and other details about the CA server

2. Above shows how to view a CA root certificate

a. Internet Explorer
a. Tools > Internet Options > Content > Certificates > Trusted Root
Certification Authorities highlight the CA and click View and then click
Details
1. Serial number Issued and tracked by the CA that issued the certificate
2. Issuer The CA that issued this certificate (Even root certificates need
to have their certificates issued from someone (perhaps even themselves)
3. Validity dates The time window during which the certificate may be
considered valid. If a local computer believes the date to be off by a few
years, that same PC may consider the certificate invalid due to his own
error about the time. Using Network Time Protocol (NTP) is a good idea
to avoid this problem
4. Subject of the certificate This includes the Organizational Unit (OU),
Organization (O), Country (C), and other details commonly found in an
X.500 structured directory (more on that later in the chapter). The

subject of the root certificate is the CA itself. The subject for a client's
identity certificate is the client.
5. Public Key The contents of the public key and the length of the key
are often both shown. After all, the public key is public
6. Thumbprint algorithm and thumbprint This is the hash for the
certificate. On a new root certificate, you could use a phone to call and
ask for the hash value and compare it to the hash value you see on the
certificate. If it matches, you have just performed out-of-band (using the
telephone) verification of the digital certificate

9. Identity Certificate
1. Similar to a root certificate but describes the client and contains the public key of an
individual host. Example would be a web server that wants to support SSL or router
that wants to use digital signatures for authentication of a VPN tunnel. Example
below:

2.

10.Using the Digital Certificates to get the Peer's Public Key

1. If we want to verify each other we send each other a copy of our digital signatures;
which will contain each other's public key and the public key of the CA. We verify
the CA using the CA public signature, and then verify each other; again by sending
some data with an encrypted hash. When receiving the encrypted hash, we use the
same hashing algorithm to run against the data and if we get the same hash we have
authenticated each other

11.X.500 and X.509v3 Certificates

1. X.500 is a series of standards focused on directory services and how those
directories are organized. Microsoft Active Directory is based off of X.500.
a. Directory elements foundation (Example)
a. CN=Bob (Common Name = CN)
b. OU=engineering (Organizational Unit = OU)
c. O=cisco.com (Organization = O)
1. org-chart way shaped like a pyramid
b. X.509v3 is a standard for digital certificates widely accepted that incorporates
many of the same directory naming standards
c. LDAP (Lightweight Directory Access Protocol)
a. Common use is having a digital certificate being used for authentication and
based on the details for that certificate (for example, the OU=sales in the
certificate itself, the user could be dynamically assigned the access rights that
are associated with that group in Active Directory or some other LDAP
accessible database.
b. Concept is to define the rights in once place and then leverage that over and
over again; like setting up Active Directory for a network and using that to
control what access is provided to each user after he or she authenticates
2. Most digital certificates contain the following information
a. Serial number Assigned by the CA and used to uniquely identify the
certificate
b. Subject The person or entity that is being identified
c. Signature algorithm The specific algorithm that was used for signing the
digital signature
d. Signature The digital signature from the certificate authority, which is used
by devices that want to verify the authenticity of the certificate issued by that CA
e. Issuer The entity or CA that created and issued the digital certificate
f. Valid from The date the certificate became valid
g. Valid to The expiration date of the certificate
h. Key usage The functions for which the public key in the certificate may be
used
i. Public key The public portion of the public and private key pair generated by
the host whose certificate is being looked at
j. Thumbprint algorithm The hash algorithm used for data integrity
k. Thumbprint The actual hash
l. Certificate revocation list location The URL that can be checked to see
whether the serial number of any certificates issued by the CA have been
revoked

12.Authenticating and Enrolling with the CA

1. Using a new CA as a trusted entity and obtaining your own identity certificate
a. Step1 The first step is to authenticate the CA server, or in other words trust the
CA server. Unfortunately, if you do not have the public key for the CA server,
you cannot verify the digital signature of the CA server. This is sort of like the
chicken and the egg story, because you need the public key, which can be found
in the root's CA certificate, but you cannot verify the signature on a certificate
until you have the public key
a. To get the ball rolling, you could download the root certificate, and then use
an out-of-band method, such as making a phone call, to validate the root
certificate. This can be done after downloading the root certificate and
looking at the hash value, calling the administrators for the root CA and
asking them to verbally tell you what the hash is. If the hash that they tell
you over the phone matches the hash that you see on the digital certificate
(and assuming that you called the right phone number and talked with the
right people), you then know that the certificate is valid, and you can then
use the public key contained in a certificate to verify future certificates which
are signed by that CA. This process of getting the root CA certificate
installed is often referred to as authenticating the CA
b. Step2 After you have authenticated the root CA and have a known good root
certificate for that CA, you can then request your own identity certificate. This
involves generating a public-private key pair and including the public key
portion in any requests for your own identity certificate. An identity certificate
could be for a device or person. Once you make this request, the CA can take all
of your information and generate an identity certificate for you, which includes
your public key, and then sends this certificate back to you. If this is done
electronically, how do you verify the identity certificate you got is really from
the CA server that you trust? The answer is simple because the CA has not only
issued you the certificate but it also signed the certificate. Because you
authenticated the CA server earlier and you have a copy of its digital certificate
with its public key, you can now verify the digital signature it has put on your
own identity certificate. If the signature from the CA is valid, you also know
that your certificate is valid and so you can install it and use it.

13.Public Key Cryptography Standards

1. A lot of standards for Public Key Infrastructure (PKI)
a. Some control format and use of certificates
a. including requests to a CA for new certificates
b. the format for a file that is going to be the new identity certificate
c. The file format and usage access for certificates
b. Few of the standards that should learn
a. PKCS #19 This is a format of a certificate request sent to a CA who wants
to receive their identity certificate. This type of request would include the
public key for the entity desiring a certificate
b. PKCS #7 This is a format that can be used by a CA as a response to a
PKCS #10 request. This response itself will very likely be the identity
certificate (or certificates) that had been previously requested
c. PKCS #1 RSA Cryptography Standards
d. PKCS #12 A format for storing both public and private keys using a
symmetric password-based key to unlock the data whenever the key needs
to be used or accessed
e. PKCS #3 Diffie-Hellman key exchange

14.Simple Certificate Enrollment Protocol

1. SCEP (Simple Certificate Enrollment Protocol) Automates most of the process of
requesting and installing an identity certificates (Not an open standard, but supported
by most Cisco devices (developed in association with some other vendors including
Cisco)
a. Process of authenticating a CA server
b. generating a public-private key pair
c. requesting an identity certificate
d. verifying and implementing the identity certificate

15.Revoked Certificates
1. One must manually check to see if a certificate has been revoked unless the device is
set to automatically check each time when authenticating.
2. Three basic ways to check in order of popularity
a. Certificate Revocation List (CRL) This is a list of certificates, based on their
serial numbers, that had initially been issued by a CA but have since been
revoked and as a result should not be trusted. A CRL could be very large, and
the client would have to process the entire list to verify the certificate is not on
the list. A CRL can be thought of as the naughty list. This is the primary
protocol used for this purpose, compared to OSCP and AAA. A CRL could be
accessed by several protocols, including LDAP and HTTP. A CRL could also be
obtained via SCEP
b. Online Certificate Status Protocol (OCSP) This is an alternative to CRLs.
Using this method, a client simply sends a request to find the status of a
certificate and gets a response without having to know the complete list of
revoked certificates
c. AAA Cisco AAA services also provide support for validating digital
certificates, including a check to see whether a certificate has been revoked.
Because this is a proprietary solution, this is not often used in PKI

16.Uses for Digital Certificates

1. HTTPS/TLS/SSL is all about the same thing.
a. HTTP combined with TLS/SSL
2. Use for a banking website for instance
3. remote-access VPNs for authenticating the peers (at each end)
4. Can also use with IPsec which can also use digital certificates for the authentication
portion
5. Use with 802.1X; authenticating a user before traffic is allowed at the edge
a. Wireless network controlling access and requiring authentication, using digital
certificates for the PCs/users, before allowing them in on the network.

17.PKI Topologies
1. Small network a single CA server may be enough
2. Large network 30,000 devices plus, a single server may not provide the
availability and fault tolerance required
a. (We are talking about a companies OWN CA server for company usage only)

18.Single Root CA
1. Having one CA server having thousands of customers who want to authenticate that
CA and request their own identity certificates might be too large of a demand on one
server
a. Offload some work by publishing CRLs on other servers
b. Still no fault tolerance though with one CA

19.Hierarchical CA with Subordinate CAs

1. You have a Root CA and subordinate or intermediary CA servers
a. The Root CA delegates authority to the subordinate CAs to create and assign
identity certificates to the clients; however the Root CA is the king of the hill
2. This is called a hierarchical PKI topology where the Root CA digitally signs the
subordinate CA certificates, and the subordinate CAs issue identity certificates to
clients
a. The Root CA certificate and it's public key, as well as subordinate CA certificates
and THEIR associated public keys are required to verify the Root CA and the
subordinate CAs all the way down the the subordinate CA that issues you a
identity certificate

20.Cross-Certifying CAs
1. Cross-certifying topology CA with a horizontal trust relationship over to a second
CA so that clients of either CA could trust the signatures of the other CA

II. Putting the Pieces of PKI to Work

1. Both routers and ASA can use digital certificates

2. ASA example

2. Default of the ASA

1. ASA by default is going to use a self-signed certificate to allow management via
HTTPS for ASDM and also for any SSL VPN clients
2. You will get a warning as it's not a trusted certificate from a CA
3. To use a trusted certificate, you need to install the Root certificate of a CA and then
request for an identity certificate

3. Viewing the Certificates in ASDM

1. ASDM has the option to configure and view both root and identity certificates

2. ff

4. Adding a New Root Certificate

1. Click Add to add a new root certificate
a. Options to install
a. From a file
b. Paste in the information
c. use SCEP
b. This option the CA supports SCEP so we choose that option

2. When adding a new root certificate you are also adding details about how you are
going to work with that CA
3. Click More Options
a. Answer questions about the CRL (Certificate Revocation List) and specify other
details about which protocols to be used for certificate verification for this
firewall to use when dealing with certificates issued by this CA

4. After you call to get the hash and compare it to your calculated hash, you can
request for an identity certificate

5. Easier Method for Installing Both Root and Identity certificates

1. Instead of manually installing a root certificate is to use SCEP to install the root,
generate a new key pair, and request your identity certificate
2. Begin in the Identity Certificate area in ASDM
3. Click Add
a. Assign a name to associate with the new CA
b. Click Add a New Identity Certificate radio button
4. To use a brand new key pair in conjunction with this CA (that will be putting your
public key into your digital certificate)
a. Click New (next to the key pair option)
b. Assign the key pair
a. A name
b. Size of the key
c. Click Generate Now

5. After clicking Generate Now

a. Public Private Key Pair is generated and the public key portion of it is sent to the
CA as part of the SCEP certificate request process
6. CLI equivalent shown below

7. Before clicking Add Certificate

a. Click Advanced to specify the details of the CA server and how to reach that CA
server

8. Specify the enrollment mode of SCEP and the IP address of the CA server that
supports SCEP shown below
9. Once the enrollment method and IP address are configured, click the OK button, and
then click the Add Certificate button

10. Equivalent CLI commands to authenticate and enroll with a new CA via SCEP

11. f

12. If the SCEP-capable CA server is reachable, and configured correctly, a success

message appears, as shown below:

13. Details of certificate

a. Highlight the certificate and click Show Details

14. REVIEW TABLE

15. f
Table 18-2 Key PKI Components
Component
Description
RSA digital
signatures

Using its private key to encrypt a generated hash, a digital signature is created.
The receiver uses the public key of the sender to validate the digital signature and
verify the identity of the peer

Digital certificate File that contains the public key of the entity, a serial number, and the signature of
the CA that issued the certificate
Public and private Used as a pair to encrypt and decrypt data in an asymmetrical fashion
keys
Certificate
authority

The CA's job is to fulfill certificate requests and generate the digital certificates for
its clients to use. It also maintains a list of valid certificates that have been issued,
and maintains a CRL listing for any revoked certificates

X.509v3

A common certificate format used today

Subordinate
CA/RA

Assistant to the CA, which can issue certificates to clients. Clients need both the
certificates from the root and the subordinate to verify signatures all the way to the
root. Used in a hierarchical PKI topology

PKCS

Public Key Cryptography Standards, agreed to and implemented by vendors who

want the ability to have compatibility with other devices in the PKI

III. Do I Know This Already? Quiz

Table 18-1 Do I Know This Already? Section-to-Question Mapping
Foundation Topics Section
Questions
Public Key Infrastructure

1-8

Putting the Pieces of PKI to Work

9-10

1. Why is the public key in a typical public-private key pair referred to as public?
a. Because the public already has it
b. Because it is shared publicly
c. Because it is a well-known algorithm that is published
d. The last name of the creator was publica, which is Latin for public
2. What is the key component used to create a digital signature?
a. Ink
b. Public key
c. Private key
d. AES
3. What is the key component used to verify a digital signature?
a. Sender's public key
b. Receiver's public key
c. AES
d. One-time PAD

4. What is another name for a hash that has been encrypted with a private key?
a. MD5
b. SHA-1
c. AES
d. Digital signature
5. What are the primary responsibilities for a certificate authority (CA)? (Choose all
that apply.)
a. Verification of certificates
b. Issuing identity certificates
c. Maintaining client's private keys
d. Tracking identity certificates
6. Which of the following is not a way for a client to check to see whether a certificates
has been revoked?
a. Look at the lifetime of the certificate itself
b. CRL
c. OSCP
d. LDAP
7. Which of the following could be found in a typical identity certificate? (Choose all
that apply.)
a. CRL locations
b. Validity date
c. Public key of the certificate owner
d. Serial number
8. Which standard format is used to request a digital certificate from a CA?
a. PKCS#7
b. PKCS#10
c. LDAP
d. TLS/SSL/HTTPS
9. When obtaining the initial root certificate, what method should be used for
validation of the certificate?
a. Sender's public key
b. Telephone
c. HTTPS/TLS/SSL
d. Receiver's private key
10. Which method, when supported by both the client and the CA, is the simplest to use
when implementing identity certificates on the client?
a. PKCS#7
b. PKCS#10
c. SCEP
d. LDAP

IV. Review All the Key Topics

Table 18-3 Key Topics
Key Topic
Description
Element

Page
Number

Text

Public and private key pairs -

444

Text

RSA algorithm, the keys, and digital certificates -

445

Text

Certificate authorities -

446

Text

Root and identity certificates -

446

List

Certificate components -

447

Text

X.500 and X.509v3 certificates -

449

List

What goes into a digital certificate -

449

Text

Authenticating and enrolling with the CA -

450

Text

PKCS standards -

450

Text

SCEP -

451

Text

Revoked certificates -

451

Text

PKI topologies -

452

Example 18-1

Commands to generate key pairs -

457

Example 18-2

Commands to authenticate and enroll with CA using SCEP -

458

Table 18-2

Key components for PKI -

461

V. Complete the Tables and Lists from Memory

Table 18-2 Key PKI Components
Component
Description
RSA digital signatures Using its private key to encrypt a generated hash, a digital signature
is created. The receiver uses the public key of the sender to validate
the digital signature and verify the identity of the peer.
Digital certificate

File that contains the public key of the entity, a serial number, and
the signature of the CA that issued the certificate

Public and private

keys

Used as a pair to encrypt and decrypt data in an asymmetrical

fashion.

Certificate authority

The CAs job is to fulfill certificate requests and generate the digital
certificates for its clients to use. It also maintains a list of valid
certificates that have been issued, and maintains a CRL listing any
revoked certificates.

X.509v3

A common certificate format used today.

Subordinate CA/RA

Assistant to the CA, which can issue certificates to clients. Clients

need both the certificates from the root and the subordinate to
verify signatures all the way to the root. Used in a hierarchal PKI
topology.

PKCS

Public Key Cryptography Standards, agreed to and implemented

by vendors who want the ability to have compatibility with other
devices in the PKI.

VI. Define Key Terms

1. PKI 2. CA 3. subordinate CA 4. root certificate 5. identity certificate 6. PKCS#7 7. PKCS#12 8. RSA 9. digital signature 10. public key 11. X.509v3 12. CRL 13. SCEP 14. LDAP -

VII. Command Reference to Check Your Memory

Table 18-4 Command Reference
Command
Description
Crypto key generate rsa Generate a public/private key pair on the ASA
Crypto ca authenticate

Retrieve and installs the root certificate via SCEP

Crypto ca enroll

Request and installs an identity certificate via SCEP