I85PREP
⌘ K
Cisco 300-720 SESA study materials
Cisco 300-720 SESA study resources

SMA Quarantine Release Fails While Partner TLS Errors Appear

Cisco 300-720 SESA · Put your knowledge to work in context.

All case studies

SMA Quarantine Release Fails While Partner TLS Errors Appear

Bridgeway Logistics uses an ESA for inbound and outbound mail and an SMA for centralized quarantine and message tracking. After a firewall change, users cannot release quarantined messages from the SMA web UI; ESA logs show 'SMA connection timed out' on port 443. At the same time, outbound mail to partner.example is deferred with '451 4.4.1 TLS required but not available'; the destination control for partner.example is set to TLS Required. Inbound mail from partner.example is also rejected at times with '454 4.7.0 TLS handshake failed'. The partner recently renewed its certificate and disabled TLS 1.0/1.1. The ESA runs AsyncOS 14.2 and the administrator wants to set the destination control to Opportunistic and disable TLS on the inbound listener to clear the errors.

1. How would you separate the SMA connectivity issue from the partner TLS issue, and why is disabling TLS the wrong response?

Read the worked answer

These are independent failures that happen to share a timeframe. The SMA timeout is an ESA-to-SMA HTTPS problem; the partner errors are SMTP TLS problems in two directions.

For the SMA:

  • Confirm the configured SMA hostname/IP and port 443.
  • Test connectivity from the ESA CLI and check the SMA certificate and web service status.
  • Review the firewall change for stateful inspection, NAT, or egress rules affecting ESA-to-SMA traffic.
  • Check mail_logs for the exact timeout and whether quarantine release calls are failing.

For partner TLS:

  • Outbound 'TLS required but not available' usually means the partner did not offer STARTTLS or the handshake failed before the message could be sent.
  • Inbound 'handshake failed' points to cipher/protocol mismatch or certificate validation on the partner side.
  • Use packet capture on port 25 and the TLS verification tools to see the offered protocols, ciphers, and certificate chain.

Disabling TLS would break the partner's security requirement and may cause mail rejection. Setting the destination control to Opportunistic would allow plaintext delivery to a partner that requires TLS, which is also unacceptable.

2. What TLS settings and certificate checks would you verify before changing anything?

Read the worked answer

Verify both directions and both roles:

  • Outbound destination control for partner.example: TLS Required is correct if the partner mandates it. Confirm the ESA is offering TLS 1.2 and an acceptable cipher suite. If the partner disabled TLS 1.0/1.1, the ESA must not be limited to legacy protocols.
  • Inbound listener: confirm TLS is enabled, the certificate is valid for the receiving hostname, the chain is complete, and the listener allows TLS 1.2. If the partner validates certificates, an expired or incomplete chain will cause handshake failures.
  • Certificate renewal: check the ESA's own certificate expiry and the partner's renewed certificate. If the partner's chain changed, the ESA's trust store may need the issuing CA.
  • Cipher overlap: compare the partner's required ciphers with the ESA listener and destination settings. A protocol match without cipher overlap still fails.

After verification, fix the specific mismatch. Do not downgrade the destination control or disable listener TLS; if a temporary workaround is absolutely required, scope it to the affected domain and document the risk.