Firewalls - Using Certification Authorities

Using Certification Authorities

Certification authorities (CAs) are responsible for managing certificate requests and issuing digital certificates. A digital certificate contains information that identifies a user or device, such as a name, serial number, company, department or IP address. A digital certificate also contains a copy of the entity's public key. A CA can be a trusted third-party, such as VeriSign, or a private (in-house) CA that you establish within the organization.
Digital signatures, enabled by public key cryptography, provide a means to digitally authenticate devices and individual users.

Certificates Provide Scalability

Without digital certificates, each IPSec peer has to be manually configured for every peer with which it communicates. Without certificates, every new peer added to the network requires a configuration change on every other peer it securely communicates with. However, when using digital certificates, each peer is enrolled with a CA. When two peers wish to communicate, they exchange certificates and digitally sign data to authenticate each other.
When a new peer is added to the network, one simply enrolls 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 own unique certificate which was issued and validated by the CA. This process works because each peer's certificate encapsulates the peer's public key, 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 own certificate for multiple IPSec sessions, and to multiple IPSec peers, until the certificate expires. When its certificate expires, the peer administrator has to obtain a new one from the CA.
CAs can also revoke certificates for peers that will no longer participate in IPSec. Revoked certificates are not recognized as valid by other peers. Revoked certificates are listed in a certificate revocation list (CRL), which each peer may check before accepting another peer's certificate.
Some CAs have a Registration Authority (RA) as part of their implementation. An RA is essentially a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.

Supported CA Servers

Currently, the firewall supports the following CA servers:

VeriSign, support is provided through the VeriSign Private Certificate Services (PCS) and the OnSite service, which lets you establish an in-house CA system for issuing digital certificates.
Entrust, Entrust VPN Connector, version 4.1 (build 4.1.0.337) or later. The Entrust CA server is an in-house CA server solution.
Baltimore Technologies, UniCERT Certificate Management System, version 3.1.2 or later. The Baltimore CA server is an in-house CA server solution.
Microsoft Windows 2000, specifically the Windows 2000 Advanced Server, version 5.00.2195 or later. The Windows 2000 CA server is an in-house CA server solution.

Configuring the firewall to Use Certificates

For site-to-site, you need to perform this series of steps for each firewall. For remote access VPNs, perform these steps for each firewall and each remote access VPN client.
You need to have a CA available to the network before you configure CA. The CA should support Cisco's PKI protocol, the certificate enrollment protocol.
When certificates are revoked, they are added to a certificate revocation list (CRL). When you implement authentication using certificates, you can chose to use CRLs or not. Using CRLs lets you easily revoke certificates before they expire, but the CRL is generally only maintained by the CA or its authorized Registration Agent (RA). If you are using CRLs and the connection to the CA or RA is not available when authentication is requested, the authentication request will fail.
Be sure that the firewall clock is set to GMT, month, day, and year before configuring CA. Otherwise, the CA may reject or allow certificates based on an incorrect timestamp. Cisco's PKI protocol uses the clock to make sure that a CRL is not expired. The lifetime of a certificate and CRL is checked in GMT time. If you are using IPSec with certificates, set the firewall clock to GMT to ensure that CRL checking works correctly.
Follow these steps to enable the firewall to interoperate with a CA and obtain the firewall certificate(s).

To configure the firewall host name:
hostname newname

For example:
hostname mypixfirewall

In this example, "mypixfirewall" is the name of a unique host in the domain.

To configure the firewall domain name:
domain-name name

For example:
domain-name example.com

Generate the firewall RSA key pair(s):
ca generate rsa key key_modulus_size

For example:
ca generate rsa key 512

In this example, one general purpose RSA key pair is to be generated. The other option is to generate two special-purpose keys. The selected size of the key modulus is 512.

(Optional) View the RSA key pair(s):
show ca mypubkey rsa

The following is sample output from the show ca mypubkey rsa command:
show ca mypubkey rsa % Key pair was generated at: 15:34:55 Aug 05 1999 Key name: mypixfirewall.example.com Usage: General Purpose Key Key Data: 305c300d 06092a86 4886f70d 01010105 00034b00 30480241 00c31f4a ad32f60d 6e7ed9a2 32883ca9 319a4b30 e7470888 87732e83 c909fb17 fb5cae70 3de738cf 6e2fd12c 5b3ffa98 8c5adc59 1ec84d78 90bdb53f 2218cfe7 3f020301 0001

Declare a CA:
ca identity ca_nickname ca_ipaddress [:ca_script_location] [ldap_ip address]

For example:
ca identity myca.example.com 209.165.202.130

In this example, 209.165.202.130 is the IP address of the CA. The CA name is myca.example.com.
The CA may require a particular name for you to use, such as its domain name.
When using VeriSign as the CA, VeriSign assigns the CA name you are to use in the CA configuration.
To configure the parameters of communication between the firewall and the CA:
ca configure ca_nickname ca | ra retry_period retry_count [crloptional]

If the firewall does not receive a certificate from the CA within 1 minute (default) of sending a certificate request, it will resend the certificate request. The firewall will continue sending a certificate request every 1 minute until a certificate is received or until 20 requests have been sent. With the keyword crloptional included within the command statement, other peer's certificates can still be accepted by the firewall even if the CRL is not accessible to the firewall.
When using VeriSign as the CA, always use the crloptional option with the ca configure command. Without the crloptional option, an error occurs when the firewall validates the certificate during main mode, which causes the peer firewall to fail. This problem occurs be cause the firewall is not able to poll the CRL from the VeriSign CA.
Authenticate the CA by obtaining its public key and its certificate:
ca authenticate ca_nickname [fingerprint]

For example:
ca authenticate myca.example.com 0123 4567 89AB CDEF 0123

The fingerprint (0123 4567 89AB CDEF 0123 in the example) is optional and is used to authenticate the CA's public key within its certificate. The firewall will discard the CA certificate if the fingerprint that you included in the command statement is not equal to the fingerprint within the CA's certificate.
You also have the option to manually authenticate the public key by simply comparing the two fingerprints after you receive the CA's certificate rather than entering it within the command statement.
Depending on the CA you are using, you may need to ask the local CA administrator for this fingerprint.
Request signed certificates from the CA for all of the firewall's RSA key pairs. Before entering this command, contact the CA administrator because they will have to authenticate the firewall manually before granting its certificate(s).
ca enroll ca_nickname challenge_password [serial] [ipaddress]

For example:
ca enroll myca.example.com mypassword1234567 serial ipaddress

The keyword mypassword1234567 in the example is a password, which is not saved with the configuration. The options " serial" and "ipaddress" are included, which indicates the firewall unit's serial number and IP address will be included in the signed certificate.
The password is required in the event the certificate needs to be revoked, so it is crucial that you remember this password. Note it and store it in a safe place.
The ca enroll command requests as many certificates as there are RSA key pairs. You will only need to perform this command once, even if you have special usage RSA key pairs.
If the firewall reboots after you issued the ca enroll command but before you received the certificate(s), reissue the command and notify the CA administrator.
Verify that the enrollment process was successful using the show ca certificate command:
show ca certificate

The following is sample output from the show ca certificate command including a firewall general purpose certificate and the RA and CA public-key certificates:
Subject Name Name: mypixfirewall.example.com IP Address: 192.150.50.110 Status: Available Certificate Serial Number: 36f97573 Key Usage: General Purpose RA Signature Certificate Status: Available Certificate Serial Number: 36f972f4 Key Usage: Signature CA Certificate Status: Available Certificate Serial Number: 36f972e5 Key Usage: Not Set RA KeyEncipher Certificate Status: Available Certificate Serial Number: 3e972n3 Key Usage: Encryption

Save the configuration:
ca save all
write memory