Using Lets Encrypt Certificate on Cisco ASA for Anyconnect (SSL) VPN

Hello guys,

I am pretty new to this, i want to know how can i create a Web Server Certificate using a CSR (created on Cisco ASA), so i can import it back to the ASA and do SSL VPN towards it?

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:

It produced this output:

My operating system is (include version): Cisco ASA 9.4

My web server is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

There’s a certbot plugin for ASA here.

You need to run it on an external box. The external box talks to LE via ACME and to the ASA using the ASA’s REST API.

LE’s authenticator validates control of the domain by issuing TLS-SNI-01 challenges to the ASA (answers pre-staged there via REST).

1 Like

Thank you, i will give it a try

nice find

going to give this a go :smiley:


@ahaw021 and @dido let us know how it goes?

Hello guys,

I cannot install the REST on the ASA while in production. The idea seems
great but the implementation for me is a bit unsure and messy and i would
definetely deploy this to a live production system on my clients. Might be
great for home use or lab but again a bit risky for everything else. Is
there any other way to submit manually a CSR and get a cert back (any
portal of Lets Encrypt)?


I cannot install the REST on the ASA while in production.

This is your local policy, I guess? Many production ASA's have the REST API enabled. It's production code from Cisco. No reason to be afraid of it IMO. Well, not more afraid of it than any other Cisco code : )

Is there any other way to submit manually a CSR and get a cert back (any portal of Lets Encrypt)?

You're not going to be able to satisfy the HTTP-01 challenge with an ASA.

You could manually do what the certbot-asa plugin does for you. This would require configuring a self-signed TLS certificate (trustpoint) on the ASA and enabling it with the ssl trust-point command prior to LE validating challenge completion. I'm not sure there's a certbot plugin which facilitates doing this manually, however.

The easiest manual approach is likely the DNS-01 challenge with certbot's manual plugin. You'd need administrative access to your Internet-facing DNS. After satisfying the challenge, you'll find the certificate, chain cert(s) and key material in the certbot config tree. A message at completion time tells you where it is.

The other option: Briefly change your DNS record so that it points at an Internet-facing box where you run certbot. Let certbot collect the certificate with the --certonly option. Then point the DNS record back at the ASA. Manually install the resulting certificate / chain cert / keypair on the ASA. The problem with this approach is that you interrupt DNS for the ASA briefly, which would not be acceptable in most environments.

Wow, that was a deteiled answer, thank you very much. Yes, you guessed it
right, any admin access to the box is allowed only on SSH and HTTPS and
only from a certain box (jump server), so it is local company policy. What
is the auth of the REST API, is it still based on the same AAA rules as the
SSH or HTTPS or only local accounts, also is the exchange of the
credentials protected vie encryption?


The REST API adds additional admin verbs to the existing HTTPS interface, and is controlled by the same http <address> <mask> <interface> directives that you have installed there already. For example, after installing the API module, you’ll find a new web interface at https://<your-asa>/doc

You’d need to add the certbot machine to the filter list.

There’s two facets to the AAA question:

  1. Authentication for incoming requests uses your existing AAA setup. No surprises there.

  2. When you enable the API, it runs a bunch of inventory commands. show version and stuff like that. If you have aaa command authorization enabled, these commands will be authorization-checked against the AAA service. But there’s no user involved. Instead, the user for these commands is ENABLE_15. I don’t know why the ASA does this. There’s an open bug about it, I think. I worked around it in my environment by adding a user with that name to the AAA server.

can you use a virtual version to do testing and then implement in production?

i can give you links to an ASA QCOW (QEMU) images

I usually do that before pushing production changes especially for new services


That is fine guys, thanks Andrei! I have a test ASA i can use, just need to
find time.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.