Skip to content
Docs sslbrain sslbrain.com

Cisco Secure Firewall (FMC)

Copy link to the page “Cisco Secure Firewall (FMC)”

← All integrations

Firewall and VPN

Renews RA VPN identity certificates and known-key decryption certificates on FTD devices managed by Cisco FMC.

The appliance runs the package and connects to Cisco Secure Firewall (FMC) through FMC REST API over HTTPS on port 443. No agent is installed on Cisco Secure Firewall (FMC).

What happens

  1. The appliance connects to Cisco Secure Firewall (FMC) through FMC REST API on port 443.
  2. For RA VPN the certificate is imported as a new PKCS12 certificate enrollment and installed on exactly the devices the policy is assigned to. For decryption an internal certificate is created from the internal server's new certificate and key.
  3. Only the selected policy's references move to the new certificate, and only its devices are deployed. If one of the devices has changes that are not deployed, the package stops without writing, because the REST API always deploys every pending change on a device. If it fails: If the deployment fails, or an RA VPN address that answered before no longer answers, the package puts the previous certificate back and deploys again in the same run.
  4. Verification: the package fetches the certificate the RA VPN addresses present over TLS, with the certificate's name as SNI, and compares its SHA-256 fingerprint with the new certificate. If it fails: If the appliance cannot reach the RA VPN addresses, the result is reported with a warning, based on configuration and deployment.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to FMC REST API, port 443. No agent is installed.
You need
A dedicated REST API user in Management Center with rights to certificates, VPN, policies and deployment. Do not use an account that also signs in to the web interface: Management Center logs one of the sessions out without warning. User name and password travel only in the login header, and the session is closed after every run.
Platform
Secure Firewall Threat Defense managed centrally by Secure Firewall Management Center 7.4 or later
Actions
Discovery, Installation, Verification, Rollback
Packages
cisco-fmc-api
Note
  • Management Center 7.7 and later: RA VPN is renewed. 7.4 and 7.6: decryption (known key) is renewed, and RA VPN is shown by discovery, because the REST API can install a certificate on a device only from 7.7. The package chooses its path from what the API offers.
  • Before anything changes, the package compares the certificate the RA VPN addresses present with the certificate Management Center and the devices have on record. When the state is not unambiguous, nothing changes, and the result carries a log without keys or passwords that can be shared with support.
  • If the policy uses an enrollment Management Center renews itself (ACME, SCEP or EST), it is taken over for the selected policy only when the rule allows it with FMC_TAKE_OVER_ENROLLMENT. That enrollment is never deleted or changed, so other policies that use it continue unchanged.
  • The previous certificate is neither deleted nor changed; it is what rollback and the automatic restore use. Rollback points the policy back only while it still names what the deploy put there, and deploys the same devices, only when no one else's changes are pending on them.
  • For decryption the known-key rule keeps the previous certificate too, so traffic to the server is decrypted both before and after the server changes its certificate. The package's own older certificates for the same server names are taken out of the rule; certificates for other servers stay. The deployment goes to the devices of the access control policies that use the decryption policy.
  • The connection to Management Center is always verified against the system trust store, a CA bundle or a fingerprint in MANAGEMENT_TLS_PIN_SHA256; a Management Center with its own certificate is pinned. An unverified connection is refused, because the package sends the account and private keys. When RA VPN is reached through NAT, the addresses for the check go in FMC_SERVICE_HOSTS; otherwise the static addresses of the devices' access interfaces are used.
  • Discovery finds Management Center's version and domains, RA VPN policies with their identity certificate, enrollment type and assigned devices, the certificate each RA VPN address presents, and the certificates in the decryption policies' known-key rules.

Certificate requirements

Key types: RSA 2048, 3072 or 4096 bits and ECDSA P-256 or P-384. Threat defense 7.0 and later refuse RSA keys under 2048 bits and SHA-1 signatures. The package does not install P-521 or EdDSA. Cisco gives no maximum RSA size for an imported PKCS12 file.

Cisco states no Common Name (CN) requirement: Cisco Secure Client checks the name against the SAN when it holds DNS names (and IP addresses when the client connects to an IP), and uses the CN only without them. The package therefore does not refuse certificates without CN, for example from Let's Encrypt's tlsserver or Google's minimal profile. A wildcard must be the whole first label (*.example.com). IP SANs are supported. Cisco gives no maximum number of SANs.

clientAuth EKU is not required. When the certificate has Key Usage it must contain digitalSignature, and an RSA certificate must also have keyEncipherment or keyAgreement; for IPsec an EKU must contain serverAuth or ikeIntermediate. An RSA certificate from a profile without keyEncipherment (for example tlsserver or minimal) is refused for RA VPN before anything changes; use ECDSA with those profiles. The requirement does not apply to decryption.

The appliance supplies certificate, chain and key as PEM. For RA VPN the package builds a PKCS12 file with the server certificate, intermediates and key, encrypted with PBE-SHA1-3DES and a SHA-1 MAC, which Cisco names for threat defense, also in FIPS mode; AES-256 can be chosen. The file may be at most 24 KB. For decryption, certificate and key are sent as PEM. JKS is not used.

Supply the chain nearest issuer first; the server certificate comes first in the PKCS12 file. A self-signed root is left out.

The enrollment's name becomes the trustpoint name on the devices: <name>-<first 12 hex of the SHA-256>, where the name is 1–32 characters (letters, digits, - and _, starting with a letter), sslbrain by default. Cisco gives no naming rule for enrollments in the sources the package is built on. The PKCS12 file's friendly name is sslbrain.

The certificate must expire before 6-2-2106. Cisco gives no minimum or maximum lifetime.

Get started