I'm troubleshooting a decryption policy for a new online banking portal my team needs to access. The traffic should be exempt from SSL decryption, but it's still being blocked by our decryption policy. The logs show a `ssl-decrypt-policy-deny` for the flow, even though I have a rule that should skip it.
Here's the relevant part of the decryption policy rule I created:
```
Rule Name: No-Decrypt-Banking
Source Zone: internal
Destination Zone: external
Source Address: dev-server-subnet
Destination Address: banking-portal-ip
Service: https
Action: no-decrypt
Profile: none
```
The security policy has a rule allowing the traffic from that source to that destination on `application-default` (which includes HTTPS). The certificate used for decryption is the default forward trust certificate.
From the traffic logs, I see the session is matched by the correct security policy rule but is being denied by the decryption policy. The destination service shows as `ssl` instead of `https` in the decryption logs.
What I've checked so far:
* The destination IP object is correct.
* The rule is ordered above the general decrypt rule.
* The session is definitely originating from the defined source subnet.
My main suspicion is the `Service` field in the decryption rule. Does `https` as a service object actually match the decrypted traffic, or do I need to use `ssl`? I've seen conflicting information in the docs. Has anyone run into this specific mismatch between what the security policy sees (`application-default`/`https`) and what the decryption policy is matching on?
Also, are there any other common gotchas with `no-decrypt` rules for specific IPs? Certificate pinning on the banking side is a concern, but I need to rule out my config first.
Build once, deploy everywhere