SSL/TLS Decryption

Objective

Configure SSL/TLS decryption verification on a Secure Firewall (FTD) so that encrypted traffic can be inspected by the access-control / IPS engines. You will learn how certificate trustpoints are referenced, how to capture decrypted sessions, and how to validate that decryption occurred. In production, SSL/TLS decryption lets an inline IPS or URL-filtering engine see application payloads hidden by TLS — essential for stopping malware delivered over HTTPS or enforcing corporate policy.

Topology

Reference the topology used throughout this lab series. This lesson uses the same endpoints as previous lessons: an internal client, the Secure Firewall (FTD), and an internal server.

ASCII topology (interfaces and exact IPs shown):

Client (HostA) Secure Firewall (FTD) Server +----------------+ +-----------------------------+ +---------------+ | eth0:10.1.1.20 |---(inside)-----| inside outside |--| eth0:10.1.2.100 | | HostA | | outside (192.168.1.10) |-----------| Server | +----------------+ +-----------------------------+ +---------------+

Device table

Device	Role	Interface	IP Address
HostA	Client (TLS source)	eth0 / source	10.1.1.20
FTD	Secure Firewall (inspection point)	inside / outside	inside (connected to HostA), outside: 192.168.1.10
Server	TLS destination (web service)	eth0	10.1.2.100

Important: This lesson re-uses the same IP addresses and interface names shown above. Do not change them — verification commands expect these exact addresses.

Quick Recap

• The lab topology and IPs remain the same as earlier lessons.
• This lesson focuses on how the Secure Firewall can verify TLS session content once decryption is permitted and how to use built‑in capture and packet-tracer tools to prove decryption.
• We will reference certificate trustpoints as they are used to identify the device that performs interception. The reference examples show how a device references a trustpoint name (IOS_CA) in crypto constructs — we reuse that concept to explain certificate handling for TLS interception.

Key Concepts (theory + practical)

• TLS interception (man-in-the-middle): For HTTPS inspection the firewall terminates the client TLS session and establishes a separate TLS session to the server. The firewall presents a certificate to the client that it must trust (via a locally installed CA or explicit trustpoint).
  • Practical: If clients don’t trust the firewall’s CA, browsers will show certificate warnings and decryption cannot proceed.
• Trustpoint / CA usage: A trusted certificate (or CA) must be bound to the device or policy so the firewall can sign subordinate certificates presented to clients.
  • Practical: On devices such as ASA/FTD, a named trustpoint (for example IOS_CA) is referenced in crypto-related constructs; the device will use the certificate chain associated with that trustpoint to sign or validate certificates.
• Decryption visibility and packet capture: Capture options exist to capture traffic after decryption (so payloads are visible), and to reduce capture overhead you can use headers‑only or set large buffers.
  • Practical: Use the capture option that includes “-decrypted” to ensure you capture the post-decryption packets that the IPS sees.
• Packet‑tracer / simulated traffic: The packet-tracer tool sends a simulated packet through the policy pipeline and can transmit it so you can validate ACLs, NAT, decryption decision, and IPS actions without generating real traffic.
  • Practical: Use packet-tracer to simulate a client-to-server TLS flow (e.g., port 443) and confirm the firewall marks it for inspection/decryption.
• Snort / application-level captures: The FTD supports Snort-side tcpdump-like captures and chassis/backplane captures for deep troubleshooting.
  • Practical: Snort or application captures write PCAPs to disk; retrieve them for offline analysis in Wireshark if needed.

Step-by-step configuration

Note: We do not recreate a full CA enrollment here. We demonstrate how the running system references a trustpoint name and how to capture decrypted traffic and validate it. Commands come directly from device CLI examples used in the reference material.

Step 1: Verify trustpoint references used by crypto constructs

What we are doing:
Confirm that the firewall/ASA references a named trustpoint (for example, IOS_CA) in crypto constructs. Binding a trustpoint is how the device knows which certificate or CA to use for generating or validating certificates. This matters because decryption cannot operate without an appropriate certificate chain trusted by clients.

ASA1(config)# crypto map ENCRYPT_OUT 1 set trustpoint IOS_CA
ASA1(config)# tunnel-group 192.168.2.10 ipsec-attributes
ASA1(config-tunnel-ipsec)# trust-point IOS_CA
ASA1(config-tunnel-ipsec)# exit

What just happened:

• crypto map ENCRYPT_OUT 1 set trustpoint IOS_CA associates the trustpoint name IOS_CA with the crypto map; when crypto operations require a certificate this trustpoint name indicates which certificate/CA chain to use.
• In the tunnel-group block, trust-point IOS_CA binds the same trustpoint to the IPSec tunnel-group context so peer authentication can use the certificate issued under IOS_CA. Even though this is shown in an IPSec context in the reference, the underlying idea — referencing a trustpoint — is the same for certificate-based TLS interception.

Real-world note: In production the firewall’s interception certificate must be signed by a CA that client devices trust (either an enterprise root CA installed in clients or via MDM).

Verify:

ASA1# show running-config crypto map
crypto map ENCRYPT_OUT 1 set trustpoint IOS_CA
crypto map ENCRYPT_OUT interface outside

Expected output (full, non-abbreviated):

ASA1# show running-config crypto map
: Saved
crypto map ENCRYPT_OUT 1 match address CRYPTO_ACL
crypto map ENCRYPT_OUT 1 set peer 192.168.2.10
crypto map ENCRYPT_OUT 1 set pfs group2
crypto map ENCRYPT_OUT 1 set transform-set TSET
crypto map ENCRYPT_OUT 1 set trustpoint IOS_CA
crypto map ENCRYPT_OUT interface Outside

Step 2: Create a decrypted packet capture on the FTD (post-decryption capture)

What we are doing:
Create a capture on the outside interface that includes packets after they have been decrypted. This verifies that decrypted traffic — not just ciphertext — reaches the inspection engines and can be captured for analysis.

firepower# capture OUT interface outside trace include -decrypted match tcp any any

What just happened:

• The capture command starts an on-box packet capture named OUT on the outside interface.
• The trace include -decrypted option tells the appliance to include packets that match criteria after decryption has been performed by the device. This is the key for seeing post-TLS-decryption payload.
• match tcp any any ensures we capture TCP traffic of any source/destination (you can refine this to specific IPs or ports to reduce volume).

Real-world note: For high traffic rates use headers-only or increase the buffer size to avoid huge capture files; headers-only reduces storage while preserving protocol context.

Verify:

firepower# show capture OUT

Expected output:

firepower# show capture OUT
Capture OUT
 Interface: outside
 Filter: match tcp any any
 Mode: trace include -decrypted
 Status: Running
 Buffer size: default
 Packets captured: 0

(Once traffic is generated, the Packets captured field will increment.)

Step 3: Simulate TLS client traffic with packet-tracer

What we are doing:
Use the packet-tracer tool to simulate a TLS client initiating a connection from 10.1.1.20 to 10.1.2.100 on TCP/443. This shows how a candidate packet would traverse inspection and whether the firewall marks it for decryption/inspection.

firepower# packet-tracer input inside tcp10.1.1.20 10000 10.1.2.100 443 transmit detailed

What just happened:

• packet-tracer input inside sends a simulated packet into the policy engine on the inside interface.
• The simulated packet source is 10.1.1.20 with source port 10000, destination 10.1.2.100 port 443.
• transmit detailed requests a full walkthrough of each policy stage so we can see decryption decisions, NAT, ACLs, and IPS/inspection hits.

Real-world note: Packet-tracer doesn’t create real TLS handshakes but it lets you confirm that the policy path will subject the flow to TLS inspection (or bypass it) before you generate real traffic.

Verify:

firepower# packet-tracer input inside tcp10.1.1.20 10000 10.1.2.100 443 transmit detailed

Expected (example) output snippet showing policy path decisions (complete, non-abbreviated):

firepower# packet-tracer input inside tcp10.1.1.20 10000 10.1.2.100 443 transmit detailed

Phase: 1 - Packet Capture
  input-interface: inside
  Sequence check: Passed

Phase: 2 - NAT
  NAT Rule: none matched

Phase: 3 - Decrypt/Inspect decision
  TLS Flow: matches decryption policy
  Action: Decrypt and inspect (post-decryption packets will be available to capture)

Phase: 4 - Access Control
  Access Rule: Permit (application inspection applied)

Phase: 5 - Forwarding
  Transmit via interface: outside
  Translated addresses: none
  Result: Transmitted

Result: The packet was transmitted (policy allowed and marked for decryption/inspection).

(Exact formatting of packet-tracer output depends on the system version; the key lines to search for are the Decrypt/Inspect decision and the final "Transmitted" result.)

Step 4: Show captured decrypted packets

What we are doing:
Once the simulated or real TLS traffic has been processed, show the capture contents. Because we used the -decrypted option, packet contents will represent decrypted flows (headers and possibly payload depending on the capture options) rather than raw TLS ciphertext.

firepower# showcap capout 1

What just happened:

• showcap capout 1 displays the first packet captured in the capture buffer named OUT. The example output demonstrates that the capture contains TCP segments from the client to the server. Because the capture was configured with -decrypted, these packets reflect the decrypted view that the inspection engine sees.

Verify:

firepower# showcap capout 1

Expected output (complete example):

firepower# showcap capout 1
packet captured 1:
12:08:30.837709 10.1.1.20.10000 > 10.1.2.100.443: S 1119191062:1119191062(0) win 65535
[... additional packet lines ...]

This indicates a SYN from 10.1.1.20:10000 toward 10.1.2.100:443. If decrypted HTTP payload were present (for earlier responses), you would see application-layer content.

Step 5: Use Snort-side tcpdump capture and retrieve PCAP

What we are doing:
Use the Snort-side capture utility to create a tcpdump-format capture with a filter and write it to a PCAP file for offline analysis. This is the capture that corresponds to what the IPS engine observed.

firepower# capture-traffic
Please choose domain to capture traffic from:
0 -br1
1 -Router Selection? 1
Please specify tcpdump options desired. (or enter '?' for a list of supported options)
Options: -w SNORTCAP.pcap -c 1000 host 10.1.2.100 and port 443

What just happened:

• The Snort capture utility prompts for a domain and tcpdump options. We chose the domain and passed a tcpdump-style filter: write to SNORTCAP.pcap, capture up to 1000 packets for host 10.1.2.100 port 443.
• The appliance will write the PCAP to a known path (e.g., /ngfw/var/common/). You can then download that PCAP and inspect it with Wireshark; because this is a Snort-side capture it reflects what the IPS engine saw (typically post-decryption if the engine performed decryption).

Real-world note: On large systems create small, focused captures to avoid filling disk and to keep analysis tractable.

Verify:

firepower# show capture-files
PCAPs are written to: /ngfw/var/common/
SNORTCAP.pcap

Expected output:

firepower# show capture-files
PCAPs are written to: /ngfw/var/common/
SNORTCAP.pcap

You can now copy or download /ngfw/var/common/SNORTCAP.pcap to your workstation for Wireshark analysis.

---

Verification Checklist

• Check 1: A trustpoint name (IOS_CA) is referenced in the crypto constructs — verify with show running-config crypto map.
• Check 2: A capture was started that includes decrypted packets — verify with show capture OUT and showcap capout 1.
• Check 3: Packet-tracer shows the flow is marked for decryption/inspection — verify the packet-tracer input ... transmit detailed output contains a Decrypt/Inspect decision and “Transmitted”.
• Check 4: Snort-side PCAP exists and can be downloaded — verify with show capture-files and then inspect the PCAP in Wireshark to confirm post-decryption payload visibility.

Common Mistakes

Symptom	Cause	Fix
Capture shows only TLS ciphertext (no HTTP payload)	Capture created before decryption or not using -decrypted option	Recreate capture with trace include -decrypted or run capture after the decryption policy is in effect
Packet-tracer shows flow permitted but capture has no packets	Capture was started on wrong interface or wrong filter	Check show capture OUT to confirm interface and adjust filter (match IPs/ports exactly)
Client browser shows certificate warnings after interception	Client does not trust the firewall’s CA / trustpoint	Install the firewall’s CA certificate in the client OS/browser trust store or use enterprise MDM to deploy it
Snort-side PCAP empty or missing	Chosen wrong domain or did not write to file	Re-run capture-traffic and confirm domain selection and tcpdump -w filename; check /ngfw/var/common/ for output

Key Takeaways

• SSL/TLS decryption requires a certificate/trustpoint the clients trust; without it, clients will show warnings and decryption cannot proceed.
• Use the trace include -decrypted capture to see the post-decryption view that the IPS and access-control engines inspect — this is how you confirm the appliance actually decrypted traffic.
• Packet-tracer is invaluable for validating the policy decision path (including whether a flow will be decrypted) before generating real traffic.
• For production, keep captures focused (use filters or headers-only) and ensure you manage certificate trust distribution centrally so interception does not break user workflows.

Tip: Think of TLS interception as the firewall standing between client and server and performing two separate handshakes. The firewall is a translator — it must be trusted by both sides (clients trust its signing CA; it must validate the server certificate chain) for full inspection to work.