Versions prior to 3.6.3 allowed renegotiated sessions to be cut through but in version 3.6.3 and later they will be rejected.
The change was intentionally made to fill a security hole whereby a user could trigger an SSL renegotiation after the session was being intercepted and decrypted. Since the SSL appliance doesn’t support renegotiations the encrypted data that followed would continue to flow through the appliance and bypass the attached appliances security policies.
This was documented in the 3.6.3 release notes:
“Decrypted SSL sessions that run into an error will now be terminated, even if the SSL intercept mechanism did not modify any of the payload in the original stream. This fixes an issue where encrypted payload was sent to the attached appliance after an error.”
Also note that this change was very specific to “Decrypt (Certificate and Known Key)” rules with ciphers that used “RSA” key exchange. All other rule types and ciphers would have been rejected when trying to renegotiate SSL in versions prior to 3.6.3.
The only work around from the SSLV perspective is to add a cut-through rule for the affected sessions. This rule can be limited to specific CN’s, IP’s etc. to maximize the number of sessions that can be decrypted.