Cisco, Microsoft, and Linux

Add an SSL Certificate to your Cisco ASA CLI

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:

  • CACertificate 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 “” 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:; 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 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
Poncho(config)# ntp server
Poncho(config)# ntp server

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 modulus 2048
INFO: The name for the keys will be:
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:

  1. 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
    Poncho(config-ca-trustpoint)# keypair
  2. 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:
    Define FQFN and x.509 Subject Name
    Poncho(config-ca-trustpoint)# fqdn
    Poncho(config-ca-trustpoint)# subject-name,OU=SSLVPN,O=Aaron Hackney,C=US,St=Texas,L=San Antonio
  3. 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:
    Enrollment Method
    Poncho(config-ca-trustpoint)# enrollment terminal
    Poncho(config-ca-trustpoint)# exit
  4. 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
    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 ‘’ 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
% Start certificate enrollment ..% The fully-qualified domain name in the certificate will be: Include the device serial number in the subject name? [yes/no]: no

Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
… snip …

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 certificate

% The fully-qualified domain name in the certificate will be:

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 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 outside


Export the Certs and Private Keys:

Backup the Keys!
Poncho(config)# crypto ca export pkcs12 mysecretpassword

If needed on a restore:

Restore Your Keys
Poncho(config)# crypto ca import 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 -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 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!

9 Responses to “Add an SSL Certificate to your Cisco ASA CLI”

  1. Campbell says:

    Hi, nice page.

    I don’t think it is importing the chain in step 4. It is only importing the 1st cert. Also the certs in the bundle are from different chains I think.

  2. Gary Wright says:

    Hey Aaron,

    Good article man! Your blog entry here helped me refresh my memory helping a customer here tonight!!


  3. Gary, Glad it helped!

  4. So just the root certificate, not the intermediates. Sounds good Cambell, I’ll give it a try.

  5. Raj says:

    Short and sweet Doc … Really loved reading it.Thanks :)

  6. Dave Funk says:

    Thank you! This procedure worked perfectly for me.

  7. Giovanni says:

    Great article!

    I have just a question.

    I need to replace a cisco ASA 5540 working as VPN concentrator with exactly the same model.
    As this replacement is urgent, we found a way to access the old “broken” device so that I am able to extract the certificates and the keys from the old one and place it in the new one.
    Is it enaugh to export the Keys and restore them in the new device or should I use the “UPDATE” method with openssl ? I don`t have very clear this point and I am asking this because actually I don`t know if simply exporting and importing the certificate from a different devices (even if exactly the same model) can generate any issue.
    Thank you

  8. Kelly says:

    Thanks for this blog, bud. This helped refresh my memory when I updated 6 ASA’s today and needed to install certs for a fqdn change. It’s sad that this exact method is so hard to find written up (this easily anyway) on Cisco’s site.

    Cheers to you for publishing it.

  9. Very insightful article on site security with ssl. Thanks, I really walked away more knowledgeable than before. ssl wildcard digital certs can secure multiple subdomains is something I recently acquired.

Leave a Reply

Powered by Wordpress | Designed by Elegant Themes