Skip to content
Docs sslbrain sslbrain.com

Cisco ASA / ASAv

Copy link to the page “Cisco ASA / ASAv”

← All integrations

Firewall and VPN

Renews the selected ASA interface certificate for AnyConnect/Secure Client VPN and ASDM with TLS checks and rollback.

The appliance runs the package and drives the Cisco ASA / ASAv command line over SSH on port 22. No agent is installed on the device.

What happens

  1. The appliance connects to the Cisco ASA / ASAv command line over SSH, port 22.
  2. Discovery matches the served SHA256 fingerprint to the ASA trustpoint. Select the interface and the entire shared VPN/ASDM binding; the management address need not be the VPN address. If it fails: An ambiguous state changes nothing; the log identifies the public state that needs clarification.
  3. The agent saves a private recovery journal on the appliance, retains the prior trustpoint and imports the PEM certificate, key and chain as PKCS#12 into a new trustpoint. It checks the imported identity before binding. If it fails: A rejected import retains the prior binding.
  4. Only the selected ssl trust-point binding changes. Every associated VPN/ASDM listener is checked by TLS handshake, SNI, chain and new fingerprint before write memory saves the configuration; the startup binding is read back. If it fails: On failure, the prior identity is restored while the binding still belongs to the run; administrator changes are preserved. A failed recovery result includes the journal reference.

Technical details

Connection
The package runs on the appliance, which connects over SSH, port 22. No agent is installed.
Service ports
443
You need
ASA administrator allowed to manage certificates, ssl trust-point and write memory. SSH requires a known or pinned host key; REST requires CA/name verification or an explicit SHA256 certificate pin. The appliance must reach all selected TLS services with their DNS/SNI name.
Platform
ASA OS 9.x / ASAv, single context and active unit
Actions
Discovery, Installation, Verification, Rollback
Packages
cisco-asa 1.0.0
Note
  • cisco-asa 1.0.0 is a signing candidate and is not yet published in the agent catalogue.
  • SSH/CLI is used on ASA 9.17+ and other models. The existing legacy REST API 1.3.1+ can be selected on documented models, including ASAv, with ASA 9.3(2)–9.16 over HTTPS 443. Discovery selects version and channel before writes; a TLS failure is not bypassed through another channel and a write is not replayed over SSH. REST is not installed or enabled. The appliance runs Bash/Python with cryptography 42+ and Paramiko.
  • A domain, VPN load-balancing or fallback binding can be shared by several interfaces and by VPN and ASDM. Discovery shows the entire affected scope. Automatic certificate management is taken over only by your choice for the selected binding; prior enrollment and keys are retained.
  • write memory saves the ASA’s entire running configuration, including other pending changes. Coordinate saving with the administrator. Keep the appliance’s private recovery journal for later rollback. ASA audit logs can contain import material; retain auditing and restrict access to those logs.

Certificate requirements

The agent’s key choices are RSA 2048, 3072 or 4096 bits and ECDSA P-256 or P-384. ASA 9.18 documents these RSA sizes and EC 256/384/521 for generation; P-521 is not an agent key choice. Generation does not establish import or TLS limits: RSA 4096 depends on the selected ASA version and service (CSCut53512). Cisco states no universal import maximum in the cited sources. From 9.16(1), weak RSA keys require an override that the agent does not enable.

The certificate must cover all selected DNS/SNI names in SAN. The agent does not require CN or substitute CN for SAN in new certificates. The cited ASA sources establish neither a CN requirement nor a general SAN-only/empty-subject boundary for every 9.x version; the imported identity is checked before binding. Choose the issuance profile for the selected VPN clients.

Secure Client 5.1 accepts absent KU/EKU. If KU is present, digitalSignature is required; RSA also requires keyEncipherment or keyAgreement, while ECDSA does not have that extra RSA requirement. An RSA tlsserver/minimal profile with only digitalSignature therefore does not meet this client rule. A present EKU must permit serverAuth. This agent does not require clientAuth for the TLS-server identity; client and IKEv2 certificates serve different roles.

Cisco describes wildcard/UCC and multiple SANs. The agent uses DNS wildcard matching and typed IPAddress SANs for IP targets; SNI uses a DNS name. The cited sources set neither a maximum SAN count nor a universal IP-SAN import limit. The agent adds no numerical SAN limit.

Inputs are a PEM server certificate, matching unencrypted PEM key and issuing chain. The agent creates password-protected PKCS#12/PFX with explicit 3DES for key and certificate encryption and a SHA1 MAC. This is the agent’s compatibility format; it does not use RC2. The sources give no ASA version boundary for AES/PBES2 import. DER and JKS are not input formats.

Supply the required intermediates from the server certificate’s issuer upwards. The agent validates chain links and omits a supplied self-signed root from the imported server chain; the TLS client’s trust store must trust the root. Cisco permits an optional CA chain in PKCS#12 but sets no universal bag-order or root requirement in these sources.

ASA trustpoint names can be up to 128 characters. The agent generates a short sslbrain name using ASCII letters, digits and dashes and uses it as the PFX friendly name; you do not select an alias. Cisco sets no mandatory friendly name or alias rule in the cited sources. Prior keys are not deleted based on name similarity.

The certificate and chain must be valid now. Cisco recommends notAfter before 2038-01-19 03:14:08 UTC for imported certificates too. The cited sources set no minimum remaining lifetime or numerical maximum validity duration; the agent adds no such duration limits.

Get started