This article attempts to address some of the common causes of SSL decode failures.
Answer:
During a connection request, if the user cancels the action or closes the browser, the initial request is sent, and the communication is identified as of SSL type, but is interrupted before completion.
If the TIM is restarted while SSL sessions are in progress, those sessions will report SSL decode failures after restart since they are incomplete as seen by the new TIM instance. After a TIM restart, the number of SSL decode failures may initially increase rapidly before subsiding.
Using a browser with very secure settings, allowing only Diffie Hellman IKE in nonaggressive mode: EDH
The APM CE TIM is not capable of decrypting traffic, as there is, as of now, no known method to gather the information required to decrypt a SSL-Connection when the IKE has been performed using Diffie Hellman in non-aggressive mode. Adjust network and application settings to eliminate this issue.
Another possible cause is traffic over port 443, but it has no SSL handshake, hence this is seen as a decode failure.