Welcome to the concluding article on the Certificate Authority series. We began this series with an overview of Cryptography and then drilled down into PKI where we saw the use of the Certificate Authority. In the last two articles, we configured the Cisco IOS router as a Certificate Server. We then used these certificates for authentication between two VPN peers.

In this article, we will look at the Local CA feature on the ASA. When this feature is enabled, the ASA is equipped with basic certificate authority functionality. It can issue digital certificates, publish Certificate Revocation Lists (CRLs), and securely revoke issued certificates.

Although the functionality is fairly similar to the Cisco IOS Certificate Server, it is not as granular and one of the main differences is that the Cisco ASA Local CA provides only browser-based certificate enrolment. This is not a disadvantage in the sense that one of the drivers for the Local CA support on the ASA was for WebVPN and SSL VPN connections. In this sense therefore, the Local CA feature is just the right level of functionality.

Let’s get right down to it. We will keep it simple and the network diagram that we will use is as shown below:

The aim is to enable the Local CA support on the ASA and get the host to enroll with this CA.

As we had with the Cisco IOS Certificate Server, we need to ensure that our clocks are synchronised in which case NTP may be useful. At this point, the clock on my ASA is correct.

Now, unlike the Cisco IOS Certificate Server which gives us the option to create an RSA key pair to use for the Local CA, the ASA does not give us that option. Instead, it generates an RSA key pair automatically when the Local CA is enabled. This means we can go ahead and define the Local CA using the “crypto ca server” command.

Notice that with the ASA, we do not specify a CA name like we did on the Cisco IOS router. This implicitly tells you that you can have only one instance of the Local CA running on the ASA at a particular time.

Now we can take a look at some of the options: “lifetime” should be familiar and it also does the same thing as on the Cisco IOS Certificate Server (i.e. it allows us to configure the lifetimes of certificates and CRLs), “issuer-name” also does the same as it does on the Cisco IOS Certificate Server. Using the “keysize” option, we can specify the size of the keypair (i.e. the same as the ‘modulus‘ option when generating a keypair using the crypto key generate rsa). This means that although the ASA will generate the keypair itself, we can specify the size to use.

Two options that may be unfamiliar are “smtp” and “otp“. Before users can enroll with the Local CA of the ASA, they must provide a username and a password. That password is a One-Time Password (OTP) generated by the Local CA and this OTP can be emailed to users (if you have a valid SMTP server on your network, for example). The “smtp” option therefore lets you configure the subject name of the email and also the sender address while the “otp” option allows you specify how long the one-time password should be valid for.

Although the OTP must be used, we do not have to send it via email; we can display it on the terminal and then send to the user which is the method we will be using. For now, let’s just configure basic settings.

We can then go ahead and enable our Local CA by issuing the “no shutdown” command.

Like the Cisco IOS Certificate Server, we also had to enter a passphrase to protect the private key. You will also notice the warning about some settings not being changeable after the CA has been enabled.

Looking at the above output, you will notice that it first generated a keypair and we can view this keypair:

As you can see, it uses a default name of “LOCAL-CA-SERVER” for the RSA keypair. Now, let’s look at the Local CA settings using the “show crypto ca server” command.

This output is similar to what we had on the Cisco IOS Certificate Server. We can also view the self-signed CA certificate generated as shown below; based on our configuration, the certificate is valid for 10 years.

This completes the steps for configuring the Local CA on the ASA. However, before users can enroll, there are still some steps that we need to perform. The first is to enable the WebVPN service on the ASA (I enabled it on the “inside” interface because that is where the host is connected).

Then, we need to configure users that can enroll with the Local CA. We do this by adding users to the Local CA user database.

Adding a user to the Local CA user database is not enough; we still need to allow the user to enroll. It is at this point that the OTP for the user is generated.

In the above output, I have chosen to display the OTP on the terminal rather than emailing it to the user. You will also notice that the user can enroll up till November 23, 2013 which is 72 hours from the time when that OTP was issued. This tells us that the default OTP expiration time is 72 hours (3 days).

Now the user can enroll with the Local CA. Remember we said that the Local CA on the ASA supports browser based enrollment. So I will open a web browser tab to https://ASA-IP-Address/+CSCOCA+/enroll.html or https://ASA-Hostname/+CSCOCA+/enroll.html. On the webpage displayed, I (or the user) will enter the username and OTP.

Hint: In case you have forgotten the OTP, you can display it again using the “crypto ca server user-db show-otp <username>” command.

Depending on what browser the client is using, the client will be prompted to open or save the certificate.

Install the certificate. On a Windows OS, the Certificate Import Wizard will come up and you can accept the defaults. The only thing to note is that it will require you to enter a private key which is the same as the OTP.

Also, because the certificate was issued by the Local CA of the ASA, you may get a warning dialog similar to the one shown below because the client system cannot validate the certificate.

However, it gives us the thumbprint of the CA server which we can use to confirm the certificate validity. As you can see from the output below, the thumbprint matches.

After installing the certificate, we can verify that it has been installed in the web browser. If you are using Internet Explorer for example, navigate to Internet Options >     Content; under the ‘Certificates’ section, click on “Certificates”.

Notice from the output above that the username – “examplepc” – has been included as the common name (CN) of that certificate. You can also see that the certificate is valid for two years like we configured.

We can view the status of the user on the Local CA user database by issuing the “show crypto ca server user-db” command. This command will show the enrollment status of the user and also the validity of the user’s certificate if available.

One way to test this certificate is to create a WebVPN tunnel-group that uses certificates for authentication. Another simpler way will be to edit the default WebVPN tunnel-group. You can view the default tunnel group by issuing the command “show run all tunnel-group“.

You will then open a web connection to https://ASA-IP-Address/ (by default, this should redirect you to your SSL VPN page) and confirm that certificates are now being used for authentication rather than the usual username/password combination.


This article brings us to the end of the series on the Certificate Authority. In this article, we have seen how to enable the Local CA feature on the ASA which supports browser-based enrollment and is useful for web-based and client-based SSL VPN connections. We have also seen how a client can enroll with the ASA Local CA.

I hope you have found the articles in this series helpful and if you have any questions comments, please feel free to use the comment box below.

Reference and helpful resource: