Public Key Infrastructure
A PKI provides centralized key management for participating network devices. It is a defined set of policies, procedures,
and roles that support public key cryptography by generating, verifying, and revoking public key certificates commonly known as digital certificates.
In public key cryptography, each endpoint of a connection has a key pair consisting of both a public and a private key. The
key pairs are used by the VPN endpoints to sign and encrypt messages. The keys act as complements, and anything encrypted
with one of the keys can be decrypted with the other, securing the data flowing over the connection.
Generate a general purpose RSA or ECDSA key pair, used for both signing and encryption, or you generate separate key pairs
for each purpose. Separate signing and encryption keys help to reduce exposure of the keys. SSL uses a key for encryption
but not signing, however, IKE uses a key for signing but not encryption. By using separate keys for each, exposure of the
keys is minimized.
When you use Digital Certificates as the authentication method for VPN connections, peers are configured to obtain digital
certificates from a Certificate Authority (CA). CAs are trusted authorities that “sign” certificates to verify their authenticity,
thereby guaranteeing the identity of the device or user.
CA servers manage public CA certificate requests and issue certificates to participating network devices as part of a Public
Key Infrastructure (PKI), this activity is called Certificate Enrollment. These digital certificates, also called identity
Certificates also provide non-repudiation of communication between two peers, meaning that it they prove that the communication
actually took place.
The digital identification of the owner for authentication, such as name, serial number, company, department, or IP address.
A public key needed to send and receive encrypted data to the certificate owner.
The secure digital signature of a CA.
Using a PKI improves the manageability and scalability of your VPN since you do not have to configure pre-shared keys between
all the encrypting devices. Instead, you individually enroll each participating device with a CA server, which is explicitly trusted to validate identities and create an identity certificate
for the device. When this has been accomplished, each participating peer sends their identity certificate to the other peer
to validate their identities and establish encrypted sessions with the public keys contained in the certificates. See Certificate Enrollment Objectsfor details on enrolling FTD devices.
Certificate Authority Certificates
In order to validate a peer’s certificate, each participating device must retrieve the CA's certificate from the server. A
CA certificate is used to sign other certificates. It is self-signed and called a root certificate. This certificate contains
the public key of the CA, used to decrypt and validate the CA's digital signature and the contents of the received peer's
certificate. The CA certificate may be obtained by:
Once enrollment is complete, a trustpoint is created on the managed device. It is the object representation of a CA and associated
certificates. A trustpoint includes the identity of the CA, CA-specific parameters, and an association with a single enrolled
A PKCS#12, or PFX, file holds the server certificate, any intermediate certificates, and the private key in one encrypted
file. This type of file may be imported directly into a device to create a trustpoint.
A CA may also revoke certificates for peers that no longer participate in you network. Revoked certificates are either managed
by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation list (CRL) stored on an LDAP
server. A peer may check these before accepting a certificate from another peer.