Solstice Retail: Decryption Rollout Versus Pinned Certificates and Unidentified Applications

Diagnosis

With forward proxy decryption, the firewall presents the client with a certificate it generated, signed by the enterprise CA. The merch staff's clients (or the portal's own client component) are pinned to the vendor's issuing chain and detect the substitution, which produces the warning and blocks authentication. Mutual TLS is a secondary complication: the client certificate exchange sits inside a session the proxy terminates, so any client-side assumption about the server chain breaks. This is a decryption incompatibility, not a trust-store distribution problem - pushing the enterprise CA to every device will not fix pinning, though it is still required for everything else.

Change

1. Create a custom URL category listing the exact partner portal domains and any authentication or CDN domains it depends on; capture those dependencies from the traffic logs rather than from vendor documentation alone.
2. Add a no-decrypt rule for that custom category, placed above the global decrypt rule and directly below any no-decrypt rules required by law (health, financial, government).
3. Scope it to the merchandising user group and to the destination category - not to all users and not to a broad category such as business-and-economy.

Compensating controls

Keep URL filtering, App-ID identification from the SNI and outer headers, and anti-spyware and vulnerability inspection on the outer session. Enable logging on the no-decrypt rule so the volume of excluded traffic is visible, and alert if the category grows unexpectedly. Maintain the domain list on a schedule with the portal owner, and document the exception with an expiry date so it is reviewed rather than forgotten. If the vendor later supports enterprise-CA issuance, remove the exception.

First, find out what it really is

Unknown-tcp means the App-ID engine could not identify the session - often because the application is not in the signature set, because it uses a proprietary protocol, or because the traffic is encrypted with something the firewall could not decode. Check the traffic logs for whether the session was being decrypted at the time. If it was not, enabling decryption for that destination often lets App-ID identify the real application and the existing deny rule may then behave correctly. Look at the session detail for the detected application, the TLS SNI if any, and whether the block is the security policy or a profile action.

If it stays unidentified

Build the narrowest rule that unblocks it:

• Destination: a custom URL category or address objects for the specific warehouse application endpoints, taken from the logs, not a subnet sweep.
• Service: tcp/8443 only.
• Application: ssl if it is TLS-encrypted and decrypted, otherwise restricted to that destination set.
• Users: the warehouse group, not all mobile users.
• Profiles: full vulnerability, anti-spyware, URL filtering and WildFire where supported - exclusion from App-ID is not exclusion from inspection.

Place the rule above the unknown-application deny rule, and add a comment with the ticket reference and review date. Where the tenant supports custom application signatures, an App-ID for the protocol is a cleaner long-term answer than a port-based rule, because it survives endpoint and address changes.

Verify and watch

Confirm the application works for a pilot group, monitor the rule hit count for a week, and check the logs for any other port or destination the app silently requires. A single-port rule that still shows denies is usually an undiscovered dependency, not a policy error.

Why it happened

URL categorisation is a database lookup, and a domain registered last month may return unknown or a low-confidence new-registration classification. The no-decrypt rule matched the financial-services category; an uncategorised domain matches nothing, falls through to the decrypt rule, and is decrypted. The rule was not wrong, it was aimed at a moving target. The same failure will recur with every new SaaS vendor, every regional domain, and every vendor that migrates between hosting providers.

Redesign

1. Destination-driven exceptions for named vendors. For any partner, portal or line-of-business app that requires exclusion, create a custom URL category containing the exact FQDNs, including authentication, CDN and telemetry domains identified from logs. Custom categories are deterministic and do not depend on external classification.
2. Keep category-based no-decrypt rules only for broad legal obligations, such as health or financial-services regulations, and accept that they will occasionally miss uncategorised sites - pair them with a monitoring alert rather than relying on them for a specific business app.
3. Do not create a blanket no-decrypt for the unknown category. It would exclude exactly the freshly registered domains that phishing most often uses, and it converts a small classification gap into a systemic blind spot. If the business insists, confine it to a named user group with an explicit risk acceptance and a short review cycle.
4. Compensate. Every no-decrypt rule still gets URL filtering, App-ID from the outer session, anti-spyware and logging. Optionally add DNS security so an excluded destination is still resolved against a threat feed.
5. Process. Add a step to vendor onboarding that captures domains, certificate-pinning status and decryption compatibility, so exceptions are designed rather than discovered through a ticket. Review all no-decrypt rules quarterly with the owners named.