Posted by Aaron Hackney
on Apr 19th, 2011 in Cisco
| 9 comments
I found this to be a less-than-clear topic: Adding an SSL certificate to the Cisco ASA.
Before we begin, let’s get our heads wrapped around a few pieces of terminology:
- CA – Certificate Authority – Issuer of a digital certificate. The digital certificate certifies the ownership of a public key by the named subject of the certificate. The certificate is the thing we buy from GoDaddy, Verisign, Thawte, etc to guarantee to web users that we really are who we say we are and it’s authenticity is assured by the CA.
- TRUSTPOINT – Declares the certification authority (CA) that our ASA should use and trust. Some examples include GoDaddy, Verisign, Thawte, etc. This will point to the issuer of our Certificate
- Intermediate Certificates – This is what we will manually load in our ASA to match the certificate we are going to buy. This will be provided by GoDaddy, Verisign, Thawte, etc. Do you remember high school algebra class. Specifically, the transitive property? If Johnny trusts Prerna and Prerna trusts Rene, then Johnny trusts Rene. Here is the example that Wikipedia gives:
If a certificate issued to “example.com” and issued by “Intermediate CA1″, and the visiting web browser trusts “Root CA”, trust may be established in the following manner:
- Certificate 1 – Issued To: example.com; Issued By: Intermediate CA 1
- Certificate 2 – Issued To: Intermediate CA 1; Issued By: Intermediate CA 2
- Certificate 3 – Issued To: Intermediate CA 2; Issued By: Intermediate CA 3
- Certificate 4 – Issued To: Intermediate CA 3; Issued By: Root CA
“For enhanced security purposes, most end user certificates today are issued by intermediate certificate authorities.”
- Public/Private Keys (Asymmetric Keys) - We create a pair of keys that unquiely match one another. Oh, and one key cannot derive another. So, I can freely give out my public key and this is perfectly safe, as my private key cannot be derived from the public knowledge of my public key. Read up on Alice and Bob here.
OK, enough of all that, let’s begin! I am going to make my domain name www.geeksrawk.com and I am going to use that domain name to access my Cisco ASA’s SSL VPN service. So, naturally, I will need an SSL certificate from a trusted authority. We need to prepare our ASA before we can create and request such a certificate.
Step 1: Make sure your ASA has an accuracte clock and calander. You can set this manually, or use an NTP server.
Set Your NTP Server
Poncho(config)# ntp server 18.104.22.168
Poncho(config)# ntp server 22.214.171.124
Poncho(config)# ntp server 126.96.36.199
If needed, make sure your ASA is aware of Daylight Savings time: (2nd Sunday in March to the 1st Sunday in November)
Adjust for Daylight Savings Time
Poncho(config)# clock summer-time CST recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Step 2: Create a public/private key pair that will uniquly identify this device. On the ASA, nothing special need be done to make the keys exportable for backup, but if you are doing this on a Cisco Router, you need to explicitly mark your keys exportable. I found out that my CA, GoDaddy, requires the key to be a minimum of 2048 bits.
General the Public/Private Key Pair
Poncho(config)# crypto key generate rsa label www.geeksrawk.com modulus 2048
INFO: The name for the keys will be: www.geeksrawk.com
Keypair generation process begin. Please wait…
Back this Key UP! If you ever need to reload or replace your ASA, your certificate will be worthless without the Private Key contained in this public/private key pair! We will do this when we are finished, but keep in mind, we must do this when we are finished for disaster recovery!
Step 3: Now, we are going to create a trustpoint. There is a lot going on in this strp, so I will break it down even further:
- Create the trustpoint and associate the public/private key pair we just generated to the trustpoint:
Associate the Key Pair with the Trustpoint
Poncho(config)# crypto ca trustpoint www.geeksrawk.com.trustpoint
Poncho(config-ca-trustpoint)# keypair www.geeksrawk.com
- Define the FQDN and the x.509 subject name. You can optionally include other information in the x.509 line identifying the location or company name, but at MINIMUM, you need: CN=www.geeksrawk.com
Define FQFN and x.509 Subject Name
Poncho(config-ca-trustpoint)# fqdn www.geeksrawk.com
Poncho(config-ca-trustpoint)# subject-name CN=www.geeksrawk.com,OU=SSLVPN,O=Aaron Hackney,C=US,St=Texas,L=San Antonio
- Now, we set up how we will enroll certificates. We can use SCEP or do it manually. Since we are only dealing with a single certificate, we are going to enroll it manually:
Poncho(config-ca-trustpoint)# enrollment terminal
- Get the Intermediate Certificate from our CA (GoDaddy, Verisign, Thawte, etc) and associate those certificates with this trustpoint. That is, we are going to tell the ASA that we trust these signing authorities based on the certificates that they give us. I got mine from GoDaddy here. This is just a flat text file containing an ASCII encoded version of the Intermediate identity certificates. We are going to cut and paste the entire certificate authority chain here. Mine from GoDaddy is a flat text file named: gd_bundle.crt. It consists of several certificates making up the certificate authority trust chain in a specific order. Here is how we do it:
Tie the Intermediate Cert Chain to the Trustpoint
Poncho(config)# crypto ca authenticate www.geeksrawk.com.trustpoint
Enter the base 64 encoded CA certificate.
End with the word “quit” on a line by itself
INFO: Certificate has the following attributes:
Fingerprint: d5df85b7 9a5287d1 8cd50f90 232db534
Do you accept this certificate? [yes/no]: yes
Trustpoint ‘www.geeksrawk.com.trustpoint’ is a subordinate CA and holds a non self-signed certificate.Trustpoint CA certificate accepted.% Certificate successfully imported
Step 4: The hardest part is really over: Setting up the trustpoint. Now, we need to sign a certificate request using the information contained in the trustpoint and the private key, the FQDN, and the CN that we generated. We will submit the request to our certificate authority, in my case, GoDaddy:
Generate a CSR
Poncho(config)# crypto ca enroll www.geeksrawk.com.trustpoint
% Start certificate enrollment ..% The fully-qualified domain name in the certificate will be: www.geeksrawk.com% Include the device serial number in the subject name? [yes/no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
—–BEGIN CERTIFICATE REQUEST—–
… snip …
—–END CERTIFICATE REQUEST—–
Redisplay enrollment request? [yes/no]: no
Copy the certificate request text from your terminal into a plain-text document. When you go apply for the certificate from GoDaddy, Verisign, Thawte, etc, you will copy and paste this request in the form provided by your certificate issuer.
Step 5: The certificate issuer will finally issue you a certificate tied to your private key and signed by the certificate authority. This will be another plain text file that we will copy and paste into our ASA.
Import the Certificate to the ASA
Poncho(config)# crypto ca import www.geeksrawk.com.trustpoint certificate
% The fully-qualified domain name in the certificate will be: www.geeksrawk.com
Enter the base 64 encoded certificate.
End with the word “quit” on a line by itself
INFO: Certificate successfully imported
Step 6: All of our hard work is about to pay off. We have a trust point configured with the CA/Intermediate certificates installed and we have our CA-signed certificate for www.geeksrawk.com. We can now use this certificate and trustpoint as a way to validate our identity to the outside world!
Use the Certificate to Identify Yourself
ssl trust-point www.geeksrawk.com.trustpoint outside
Step 7: BACKUP THOSE KEYS!!
Export the Certs and Private Keys:
Backup the Keys!
Poncho(config)# crypto ca export www.geeksrawk.com.trustpoint pkcs12 mysecretpassword
If needed on a restore:
Restore Your Keys
Poncho(config)# crypto ca import www.geeksrawk.com.trustpoint pkcs12 mysecretpassword
***** UPDATE ******
If you need to import a certificate and a keypair that were NOT generated on your ASA device:
1. Convert the PFX to base64
openssl base64 -in mysite.com.pfx -out mysite.pem
2. Import the base64 version of the PFX file to the ASA using the password that was used to create the original PFX:
asa(config)# crypto ca import mysite.com.trustpoint pkcs12 mySecretP@ssw0rd
Enter the base 64 encoded pkcs12.
INFO: Import PKCS12 operation completed successfully
If you need to EXPORT your Cert and Key from the firewall, the command referenced above in the export section produces a file that is base64 encoded. To get to the PEM format, you will need to decode the Base64 version into a regular pfx file and then you can convert the pfx file to a PEM. There well may be a more direct method, but this works and I stopped looking!
openssl base64 -d -in exportedcert.crt -out exportedcert.pfx
openssl pkcs12 -in exportedcert.pfx -out exportedcert.pem -nodes
The next article will focus on using the certificate to enable your SSL VPN. Until next time, Adieu!
Leave a Reply