Cisco ASA Anyconnect licensing for dummies, updated!

The picture below should be self-explaining. Click it for a larger version.

Edit 2014: There was some errors in the logics around AEA-licenses. The picture below is now corrected. Please do not use the old version (v1.1).



Let me explain this.


First of all, Advanced Endpoint Assessment (AEA) is a feature where you can do advanced posture checks and remediations with AnyConnect. AEA can check if your antivirus is enabled, and if not enable it, verify if the clients software firewall is installed and enabled and other advanced remediation thingies. I have never used it and if you are not certanly sure you don´t need this license. But if you do you need to continue on the Anyconnect Premium track. No Essentials license for you, my friend.


So. The big question is: Premium licenses or Essentials? The big (simplified) answer is: do you want to use the “clientless” portal? This requires premium licenses and cannot be used if you have “anyconnect essentials” configured (which in turn require the essentials license, see below).

So, let´s say that you need premium licenses. These comes in chunks of concurrent users from 2 to 10, 25, 50 and so on. These are not additative. If you have 2 you can go to the fixed steps of 10, 25, 50 and so on. If you have 25 you can go to 50, 100, 250 et cetera. Each combination of number of license you HAVE and the number of license you WANT have a specific product number. One from 10 to 25, one from 10 to 50, one from 25 to 50 and so on. Messy? Indeed.


The cheaper track is the essentials-licens. You unlock your firewall to unlimited(*) number of concurrent vpn client with one single license. It is cheaper and easier but comes with a few downsides: If you use essentials you cannot do the portal-thingie. And you can not use AEA (which is probably not an issue, see above).

If you wanna use essentials you add the license, AND you do not forget to add the command “webvpn -> anyconnect-essentials” to enable essentials. This command cannot be entered without the license and when essentials is enabled the firewall doesnt care if there are premium licenses installed or not.


On the other hand, if you use premium licenses, you must (except for adding the licenses of course) disable essentials (webvpn -> no anyconnect-essentials). The essentials license (if it exists) will stay there but for no use and good.


So, can it be even more complicated? You bet! No matter what selections you have done above you cannot use anyconnect in your mobile device (iOS, Android). Why? Because Cisco wants to sell “Anyconnect Mobile” licenses. Don´t worry, they are cheap. But you need to add this if you want mobile clients. It is a binary one-timer. You add one mobile-license and you can also use mobile vpn clients.


So, let´s have a look at a few examples:


Example 1: We have an ASA5510 on which we want to connect numerous of anyconnect clients. We don´t care about the portal, but we want to use mobile clients.  We add these licenses:

  • one L-ASA-AC-E-5510=
  • one L-ASA-AC-M-5510=

The 5510 platform can handle 250 concurrent vpn sessions. This means that the licenses above allows us to use 250 concurrent connected vpn-clients, and among them there can be any number of mobile clients. (Dont forget to enable essentials in the config!)


Example 2: An ASA5520 on which we want to use the clientless portal as well as anyconnect clients up to a number of 45 concurrent sessions. We add this license:


  • One L-ASA5500-SSL50


Now we had raised the number of concurrent vpn-sessions from the built-in 2 to 50. Since it is premium licenses any of these 50 sessions can be clientless portal users.


Example 2b: We want to raise the number of concurrent users from 50 to 100. We also want to allow iPhone-devices to connect with AnyConnect. We add these licenses:


  • One L-ASA-SSL-50-100=
  • One L-ASA-AC-M-5520=


Sounds complicated? Only the first 20 times you need to understand the licensing model. And everytime Cisco changes it. Which happens. :-)

Tagged with: , ,
Posted in Cisco Security

DNSSec Zone signing

This is what happens when a zone is signed with DNSSec:

  1. 2 Keypairs are created, named ZSK and KSK.
  2. The public keys ZSKpub and KSKpub are added to the zone file as DNSKEY RR:s
  3. All existing entries in the zone files are signed with the ZSKpriv. The signatures are added to the zone files as RRSIG RR:s.
  4. The added DNSKEY RR:s (ZSKpub and KSKpub) are signed with KSKpriv. The signatures are added to the zone file as RRSIG RR:s.
  5. A hash of KSKpub is transfered to the parent zone.


To visualize this we will sign the fictive zone This is the unsigned zone file:

$TTL 300 IN SOA (
3H    ; Refresh after three hours
1H    ; Retry after one hour
1W    ; Expire after one week
1D )    ; Minimum one day TTL

@                IN    3600    NS            IN    A

www                IN    3600    A


This zone file is heavily simplified. It contains one SOA-record, one NS-record and 2 A-records. So, let´s take a look at what happens when the zone is signed, step by step:


Step 1: 2 Keypairs are created, named ZSK and KSK.

In the configured key directory 4 files are created

Each public key is stored in the files named .key and the content looks something like this: IN DNSKEY 256 3 8 AwEAAdNMI9iWcmphYDJPqAHxuAkduG7uF1UNy/OKrumEXxOZfGydiEDk 7++Yx75UxOWsAvG7MIUXQWthGj59XfRAIfKxcJr+XhpnQdX2rtjPAj8v zJ2ZB/c8iKmYzUQ85pUoHM6TN+/1wfARFfWK1+FmpGPB0pYBDWpLUmDb JAJkREQz

Its private equivalent is named .private and the content of the file looks like this:

Private-key-format: v1.3
Algorithm: 8 (RSASHA256)
Modulus: 00wj2JZyamFgMk+oAfG4CR24bu4XVQ3L84qu6YRfE5l8bJ2IQOTv75jHvlTE5awC8bswhRdBa2EaPn1d9EAh8rFwmv5eGmdB1fau2M8CPy/MnZkH9zyIqZjNRDzmlSgczpM37/XB8BEV9YrX4WakY8HSlgENaktSYNskAmRERDM=
PublicExponent: AQAB
PrivateExponent: K2ftyTWGxZHBaDRy6AtW6hB/7dHdWyydZCduLSxzN5yFMe7eqa4eGBNDnTbex+uhIzV4Dy8q0js9X+7zGRT/o/KPdyxr9y4xBeruKXwHl8nKVdaUsgr21z7zDZ5emlqoPHQ9XryohQyiWgN3qYIU3Cm5de6gl5+Sx5FLaQZjnUE=
Prime1: /+S4XclcoTX2Vnz+ZOGyEdgsz+kofAZfAJazzFVMbc+GBv+7SsjB5PpDwOrxdMSBgq2SYveecjlVwDHiwAOwEw==
Prime2: 02KqZt4b6g6cEOojse02yAEclqTou6mNs+mUk7QCyQvekVGl+mnZqpa/bQ/jMMnXNPDOJTv+KKY1aZLVPUrfYQ==
Exponent1: m5nNziHCdLjmeQL6ggeHizhDT428s2YAYNBCto5rsh5NpnXcwoW++WiAyI9UkadoBTlcWVeu/lAE56Ct/AqCBw==
Exponent2: rxYbRGcWQfDl7dCxzi9IX7MkBdcD+mR/PZTsfsbsQ7A0IrO5QcgpBXYlimVNbdzRB0Wpygd+BhddSFvZihIZIQ==
Coefficient: 2PGzkxeMAtwZi9kgbq8Lb57z8q/flqC92rTU/5iymhOshvilVTX347FS9PZzcN3tsdHG2HCJ8OVAZzlpIoOcuQ==

Step 2. The public keys ZSKpub and KSKpub are added to the zone file as DNSKEY RR:s

The content of the .key-files are added to the zone files with some additional comments:

300     DNSKEY  256 3 8 (
) ; ZSK; alg = RSASHA256; key id = 8565
300     DNSKEY  257 3 8 (
) ; KSK; alg = RSASHA256; key id = 62671

Step 3: All existing entries in the zone files are signed with the ZSKpriv. The signatures are added to the zone files as RRSIG RR:s.

So, which is which above? Take a look at the number following directly after “DNSKEY”. 256 and 257. The one with the odd number is the KSK. So Key with ID 8065 is our ZSK and 62671 is the KSK. Now, dive into the signed file and have a look. Directly below each original record (SOA, NS, A, A) we have new RRSIG:s:        300    IN SOA (
2014020320 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
86400      ; minimum (1 day)
300    RRSIG    SOA 8 2 300 (
20140504081944 20140404071944 8565
ifd1ZN3ytmwK2+mAJzEnwt8meFs= )
3600    NS
3600    RRSIG    NS 8 2 3600 (
20140504081944 20140404071944 8565
t5VxrQ7mJjSt0MMZImiUaI4XkfM= )        300    IN A
300    RRSIG    A 8 3 300 (
20140504081944 20140404071944 8565
eUfdRHjeBCKb6w6CWgPlpx4x0AM= )        3600    IN A
3600    RRSIG    A 8 3 3600 (
20140504081944 20140404071944 8565
kKKPWYK9GHbMWE3z4Hxwdu4PC5w= )

Note that each RRSIG has the key-id 8565 included in the record to show which key the signature is created with (the ZSK)).


Step 5: The added DNSKEY RR:s (ZSKpub and KSKpub) are signed with KSKpriv. The signatures are added to the zone file as RRSIG RR:s.

300    RRSIG    DNSKEY 8 2 300 (
20140504081944 20140404071944 8565
QyLcEBUibhpRStop32tOrImXjsU= )
300    RRSIG    DNSKEY 8 2 300 (
20140504081944 20140404071944 62671
6yNf6Rlvg7vNmfpZeA== )

Step 5: A hash of KSKpub is transfered to the parent zone.


Instead of sending the entire KSKpub to the parent zone, a hash called DS-set is created. This is smaller than the key itself and the reason for making a smaller DS-set is to save space in the parents zone files. This DS-set is created as a separate file named dsset-<zonename>. in the same directory as the keys. The content of this file is to be sent to the parent. The routine how to do this can differ depending on which registrar your zone is connected to. I have seen situations where the ds-set is sent to the registrar with email but the most common way to do this is to upload the DS-set to the registrar in a web form. This is how the DS-set can look like:        IN DS 62671 8 1 99511969D3C5A88E49533476E401A6C9FF0FC5C2        IN DS 62671 8 2 6F355545ECDB637BA287C62A075DC28A224AAEDEC6233AA28FC3035C 33557A8D

Disclaimer: This post explains the basic of zone signing. In reality there are a few more things that complicates this even more, like NSEC and double ZSK:s. These topics are to be explained elsewhere. :-)

So, the chain of trust gives that


  • A specific DNS-record is protected with a signature made with ZSK
  • The ZSKpub is protected with a signature made with KSK
  • The KSKpub is protected with the DS-set stored by the parent.

“Above” that the chain of trust continues all the way up to the root zone “.”.



Posted in Uncategorized

Site refreshments

This site has gone thru a number of changes. First of all the look&feel has been modified slightly, but the most changelling changes are in visible, and was done to tighten and raise the security level. This is what happened:


In order to secure the domain we have implemented DNSSec. This is done in a “Hidden Master” fashion and the private keys are kept somewhere without direct contact with internet.

Screenshot 2014-03-26 13.36.21

Results from .SE dnscheck validating the domain



The site is SSL only. Not that you can find any secret information here that needs to be protected, but the overall gut feeling that there is an end-to-end security between your browser and this server hopefully makes us all feel better. Of course the cipher suite uses Perfect Forwarding Secrecy. :)


Output from the Firefox plugin "Calomel SSL Validation"

Output from the Firefox plugin “Calomel SSL Validation”

WordPress hardening

A number of action has been taken to make sure that all software run here are as secure as possible. This includes running vurneability scanners to find holes to tighten, as well as a number of best practice security tweaks for Apache and WordPress.

Screenshot 2014-03-26 13.35.48

Besides from specific hardening steps the most crucial thing to keep in mind is to make sure that WordPress as well as all plugins are recent and updated as possible. This is an ongoing step and I try to have a look in the admin panel as often as possible to see if it notifies me about available update for as well WordPress core as the active themes and and plugins.

Network Design

This site is run on a VM. It is placed on a separate DMZ separated from everything else. A full backup is run and securely moved off-site every night for fast recovery if something would happen.

A disaster backup machine is available elsewhere and in case of a major fault everything can be restored to this machine relatively easy.


Posted in Uncategorized

Sha1 is dead! Or at least dying…

As you all hopefully know by now, Microsoft released a security update that disallow the use of RSA keys with a key lenght below 1024 bits. And now there is a new important security advisor from MS with news on certificates in the platform.

This time they are issuing a recommendation to discontinue the use of SHA-1 as a hash algorithm in certificates. SHA-1 was published in 1995 and as we all know, a lot of things have happend in the IT industry since then. And considering that NIST recommended to move away from SHA-1 as early as 2005 we probably should have done this a long time ago. But as a matter of fact, up to 98% of the certificates in use today uses SHA-1 tells us that is not the case.

So how will this security advisory impact us? Well nothing will happen right away, it will take a couple of years before MS will stop the use of these certificates. But the SHA-1 deprecation policy says the following:

Will apply to Windows Vista and later, and Windows Server 2008 and later. (All supported OS)
CAs must stop issuing new SHA-1 SSL and Code Signing certs by 1 January 2016.

SSL Certificates
Windows will stop accepting SHA-1 end entity certificates by 1 january 2017. This means that all valid SHA-1 SSL certificates must be replaced at this date.

Code Signing Certificates
After 1 January 2016 Windows will stop accepting SHA-1 code signing certificates. But there will be an exception. If the signed code have a time stamp it will still be accepted until further notice. So the first step is to make sure that all code from now on should be time stamped when signed. And then you should issue a new code signing cert with SHA-2 as soon as possible.

Microsoft Root Certificate Program
Members in the Root Certificate Program will not be allowed to issue certificates using the SHA-1 hashing algoritm for the purpose of SSL and code signing after January 1 2016

MS Security Advisory 2880823 (

The effect on Microsoft Root Certificate Program. (

Tagged with: , , ,
Posted in Uncategorized

Ironport WSA https-certificate import

Memento: When exporting a root certificate (with its private key) from a Microsoft Root CA you get a pkcs#12-file (.pfx). In order to import this cert and key into the Cisco Ironport WSA as a root certificate you need to do this:


  1. Move the .pfx-file to a machine with openssl installed
  2. Run “openssl pkcs12 -in myinfile.pfx -out myoutfile.pem -nodes
  3. When prompted enter the password you used when exporting the cert/key on the CA server.
  4. Open the myoutfile.pem file in a texteditor.
  5. Copy the lines beginning with (and including!) the line “—–BEGIN CERTIFICATE—–” and until the end of the line “—–END CERTIFICATE—–”.
  6. Paste that content to a new file and save it to something like cert.pem
  7. Open the myoutfile.pem again in a text editor.
  8. Copy the lines beginning with line “—–BEGIN RSA PRIVATE KEY—–” and ending with the line “—–END RSA PRIVATE KEY—–”.
  9. Paste the content to a new file and save it to something like key.pem.
  10. Select the files as Certificate and Key respective in the WSA GUI under Security Services-HTTPS Proxy-Edit Settings…-Root Certificate for signing-Use Generated Certificate and Key.

I have googled this so many times now. Hopefully google will index this rapidly and next time I google it I will see my own blog post as the first search result. :-)

Memento is… oh sorry, forgot what to write here…

Posted in Uncategorized