Showing results for 
Search instead for 
Did you mean: 

Understanding and Configuring the ASA with an EC certificate and EC ciphers



Elliptical curve ciphers use much shorter key lengths than the RSA keys that we have traditionally used. We understand elliptical curve keys with short key lengths provide similar strength as RSA keys with much longer length.

Symmetric Key 

length (bits)


length (bits)


length (bits)

80 1024 160
112 2048 224
128 3072 256
192 7680 284
256 15360 521

The reduction in CPU time to work with the larger keys is optimal due to the reduction in CPU usage and the subsequent reduction in power.

RSA public key algorithms are not considered legacy as of yet. It is likely that they will be in the next several years. In practice RSA key pairs are becoming less efficient each year as computing power increases. Elliptic curve cryptography is a newer alternative to public key cryptography. Elliptic curves are very efficient and offer the same level of security over much shorter prime fields and therefore the performance of ECC is significantly better than RSA public key cryptography. ECC is considered Next Generation Encryption by the US National Security Agency.


  1. In ASA OS 9.4(1), released March 22, 2015, the ASA started supporting several new cipher suites.
  2. In ASA OS 9.3(2), released December 18, 2014, the ASA started supporting Transport Layer Security version 1.2.
  3. In ASA OS 9.0(1), released on October 29, 2012, the ASA started supporting using ECDSA key pairs for generating certificates.
  4. AnyConnect v4.x is required, Apex or Plus license.

Both 9.4(1) and 9.3(2) require Next Generation ASA.  They will not run on older ASA models like the ASA 5505, 5510, 5520 or 5540.

Assure you do not have anyconnect-essentials configured under webvpn.  AnyConnect Essentials license does not support these ciphers and isn't in use when the Apex or Plus AnyConnect 4 license is installed. 

Understanding Cipher Suites

You can view all the ssl cipher suites that the ASA supports by typing

show ssl ciphers

Each cipher suite has several parts.  These are a key exchange and establishment algorithm, a bulk encryption algorithm, a message authentication code algorithm and a pseudorandom function.


Let’s look at this cipher suite as an example.


In the cipher suite listed above

The key exchange algorithm is ECDHE-ECDSA.

The bulk encryption algorithm is AES256-GCM.

The message authentication code is SHA384.


ECDHE is an asymmetric algorithm used for key establishment.

ECDSA is an asymmetric algorithm used for digital signatures.

AES256-GCM is a symmetric block or bulk cipher used to protect the ‘data’.

SHA384 is a hash function used to assure the data’s integrity by the receiving party.


The ASA supports lots of other cipher suites and we will not discuss those here.



There are several things we need to do here

  1. We need to create an ECDSA key pair on the ASA. 
  2. We need to create an CSR and submit that to a 3rd party certificate provider
  3. Install the certificate we receive from the 3rd party provider.
  4. Configure the ASA to only support elliptic curve ciphers.

Step 1 & 2.

Creating a SHA-2 CSR using ECDHA

See this other document I wrote for this procedure.


Step 3.

Install the Identity Certificate and Intermediate Certificate you receive from the 3rd party provider.

Authenticate the CA

crypto ca authenticate

Install the Identity Certificate

 crypto ca import

Step 4.

I chose to only support TLSv1.2.  I did this because all modern OS’s and browsers support TLSv1.2.  I also chose to only support elliptical curve cipher suites. All modern OS’s and browsers support elliptic curve ciphers.  If you need to provide support to Windows XP or Mac OS X 10.5 or earlier you cannot exclusively use elliptic curve ciphers.

Force the minimum version of TLS to be 1.2

 ssl server-version tlsv1.2

Force TLSv1.2 to only support elliptical curve sipher suites


Force strong Diffie Hellman key exchange

ssl dh-group group24
ssl ecdh-group group20


At this point it is my feeling that the ASA is configured to use the strongest encryption key exchange and encryption that is possible. 

You can test this by going to an SSL testing website like Qualys SSL Labs and testing your site.  At the time of this writing (March 2016) my ASA is receiving an A- grade score with the above settings.

Qualys SSL Labs 


  1. Cipher Suite
  2. GlobalSign ECC
  3. ASA version 9.0(x) Release Notes
  4. ASA version 9.3(x) Release Notes
  5. ASA version 9.4(x) Release Notes
  6. Next Generation Cryptography
  7. NSA Suite B Cryptography

Please, help me make this document better.  Please comment! Please rate.  Thank you.

Hall of Fame Master

Great document Glen.

I would add that you can use the nmap script "ssl-enum-ciphers" to check your ciphers as well:

Regarding the Qualys check, as far as I can tell, it's not possible (using only ASA configuration settings) to eliminate the "Secure renogotiation" and "forward secrecy" scoring reductions that prevent you from getting an A+.


[@mrhoads-cco]    Thanks for the compliment, I really appreciate it. 

I agree that secure renegotiation and forward secrecy were not configurable options in 9.4 and I don't believe they are configurable in 9.6(3) either.   

Additionally, I had hoped and researched OCSP stapling which also isn't supported. 

Not applicable

Hello Tim,

My client wants to start using Windows 10 VPN Client instead of Anyconnect.

Use certificate based authentication for 2FA

We have ASAs running 9.6 (2) or 9.6(3).

Ive been told the windows 10 machine certificates only support  ECDSA .

Would this solution work ?


Hi Tim and Marvin,

I have a question regarding ECDSA.


I have two FP4120 with ASA Code 9.7. These two boxes are configured with SSL VPN using AnyConnect 4.4. We have a 3rd Party CA, I generated the CSR from 1st ASA and submit to CA to have it signed.

I was able to install all the certs (Root, Intermediate and Device Cert) in the two boxes. After I exported out the device identity cert of 1st box and import it to the 2nd box. I encountered a warning message on the 2nd ASA box when I assigned the trustpoint to the external interface. "Unable to find trustpoint" message. 

At first, I thought there was a problem with the device certificate. So I tried to submit again a new CSR to our CA but this time, I generate the CSR from the 2nd box. After I install the new cert on the 2nd box, I export out the identity cert and import it to the 1st box and now, the warning message appears on the 1st ASA box. 

It seems weird that even though the ASA parse a warning message, it still able to assign the trustpoint to the external interface and the certificate was properly associated as well. I verified it with sh crypto ca certificate <trustpoint name>. But when I tried to test the anyconnect, the ASA used the default-self-signed cert, coz it prompted the anyconnect client with untrusted certificate error. Which supposed to happen because of the warning message. 

To further isolate the issue. I tried using RSA for the device identity cert. I export and import the cert from the two ASAs and vise versa assigned the trustpoint to the external interface and found no issues. It looks to me that ASA 9.7 code using ECDSA cannot be installed or used to multiple devices. 

Any thoughts on this? 

Thank you in advanced. Appreciate your inputs on this.


[@john.dejesus]   Is your device configured for both RSA & EC ciphers ?  See Step 4 above. 

Also please post the output of   show runn all ssl.


Sorry but I have no experience using the Win 10 VPN client.   I'd be surprised if Win 10 *only* supported EC for Machine certs though.   RSA certs are still widely deployed.  Can you please post source reference for that ?

I did a few google searches and found:

RSA Keys need to be longer than 1024 (thank goodness)

Windows 10 Cipher Suite Support



Hi Tim,

I followed your steps and I tried also setting it to "All" but still getting the same warning message.

I also tried this - "How to generate SSL certificates for use with VPN Load Balancing ASAs?" on this link

But the link above seems working only for RSA not on EC. I am sure that I'm missing something on the config I just don't know where to look now. 

I have attached the screenshot of the error.


Would you be able to SSH to the device and run the following command ? 

show runn all ssl



Below is the output

ssl server-version tlsv1.2
ssl client-version tlsv1.2
ssl cipher default custom "AES256-SHA:AES128-SHA"
ssl cipher tlsv1 custom "AES256-SHA:AES128-SHA"
ssl cipher tlsv1.1 custom "AES256-SHA:AES128-SHA"
ssl cipher tlsv1.2 all

ssl cipher dtlsv1 medium
ssl dh-group group2
ssl ecdh-group group19
ssl trust-point ASDM_TrustPoint4 Ext_DMZ
ssl trust-point ASDM_PKI management
ssl trust-point ASDM_TrustPoint4 Ext_DMZ vpnlb-ip
ssl certificate-authentication interface Ext_DMZ port 443


Try adding the following command to your config. 

ssl cipher tlsv1.2 medium

Medium forces the ASA to use EC Ciphers first. 

Additionally since you have you are forcing the ASA to use TLS v1.2 for client and server connections. 

ssl server-version tlsv1.2
ssl client-version tlsv1.2

As such, these don't matter. 

ssl cipher tlsv1 custom "AES256-SHA:AES128-SHA"
ssl cipher tlsv1.1 custom "AES256-SHA:AES128-SHA"

Let me know if that resolves the Self Signed Cert issue.

Separately I would add these commands to your config too.

DH Group 2 is weak and while DH Group 20 is acceptable its the weakest curve available. 

ssl dh-group group24
ssl ecdh-group group20

Also, please rate if helpful! 


Hi Tim,

I also followed the commands you stated above. But it looks like the ASA02 for example cannot find the trustpoint. Even though in output of "sh crypto ca cert" shows that the cert was associated to the trustpoint but for some strange reason the ASA02 cannot able to recognized it when a connection attempt was made. 

Another strange thing happened was when I reload ASA02, the ASA02 cannot able to find the trustpoint and key pair. Hence, it will delete the certificate chain that was previously associated, and it will prompted an error "device certificate was not installed". See attached sample screenshot.

I now beginning to suspect that this is some kind of bug when you try to export the pkcs12 certificate (ecdsa based) and import it to another box. Because I tested this same scenario using rsa based cert but I did not encounter such problems.

Not applicable

Hi Tim,

Thank you for the above information.

Its a client requirement to use only EC on Windows 10.



Just to update you guys. Cisco has opened a bug case on my issue. It will be patched this coming few months.



Hall of Fame Master

Thanks for the update John.

Did they give you a BugID number?


Hi Marvin,

Here is the link