FTD 7.2.5.1 → 7.6.2 Upgrade sftunnel TLS Failure — Certificate Mismatc

[Alain Nohra]

Hi everyone,

I’d like to share a troubleshooting experience during an upgrade from FTD 7.2.5.1 to 7.6.2 on a Firepower 4115 HA pair managed by FMC, and how we ultimately resolved a persistent sftunnel communication failure related to certificates.

Environment

• FMC: 7.6.x

• FTD HA Pair: Firepower 4115

• Upgrade Path: FTD 7.2.5.1 → 7.6.2

• Upgrade initiated from FMC

Symptoms

During the upgrade workflow:

• Secondary FTD appeared to upgrade successfully locally

• FMC remained stuck at 70% (“Waiting for secondary device to become ready”)

• Primary FTD upgrade never started

• sftunneld on FMC repeatedly logged TLS failures

• FTD registration attempts timed out

• RabbitMQ errors were seen

• Connectivity (ping / telnet 8305) and TLS handshake were successful, but post-handshake auth always failed

Typical FMC log snippet:

Unable to set Post Handshake Auth SSL context: SSL_verify_client_post_handshake:extension not received Failed to reload credentials Failed to add services Peer <device> needs re-connect

Root Cause

We determined that the InternalCA certificate chain was mismatched between FMC and the Secondary FTD during the upgrade. Specifically:

• FMC was using a current InternalCA

• The FTD was still presenting an older sftunnel certificate signed by a different CA

• TLS handshake would succeed, but post-handshake client authentication failed

• This prevented stftunnel from establishing a stable management channel

• FMC could not mark the upgrade stage as complete

How We Verified the Certificate Issue

We used OpenSSL on both FMC and FTD to inspect the sftunnel certificate:

openssl x509 -in /etc/sf/keys/sftunnel-cert.pem -text -noout

This allowed us to confirm the:

• Certificate Issuer (InternalCA CN)

• Validity period

• Extended Key Usage

Mismatch in the Issuer/CA between FMC and FTD was the key indicator.

Resolution Steps

1. Cleaned up old sftunnel certificates and CA roots on the FTD

2. Re-registered the FTD to the FMC so the correct CA was pushed down

   • Ensuring the FTD and FMC used the same InternalCA

3. After fixing the certificate alignment, we set TLS back to TLS 1.3 on the FTD in the sftunnel.conf

4. sftunneld immediately came up successfully

5. The FMC upgrade task resumed

6. Both firewalls successfully upgraded to 7.6.2

Official Cisco Guide on Regenerating sftunnel Certificates

We also followed the Cisco documentation to ensure correct regeneration of sftunnel CA and certificates: https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center-4600/222464-renewal-of-fmc-sftunnel-ca-certificate-f.html#toc-hId--1045197782

This guide was useful to understand the correct behavior of sftunnel CA regeneration and when to apply manual cleanup vs. re-registration.

Final Result

• sftunnel became stable

• FTD re-registered successfully

• RabbitMQ service resumed

• Upgrade completed for both HA units

• Both nodes on FTD 7.6.2 and reporting healthy status

Key Takeaway

If an upgrade stalls around 70% with post-handshake TLS errors on sftunneld, even with base connectivity intact, the issue often lies in certificate/CA mismatch between FMC and FTD — especially in upgrades spanning multiple major versions.

Use:

openssl x509 -in /etc/sf/keys/sftunnel-cert.pem -text -noout

to verify certificate details and confirm CA alignment.