Evgueni,
I have a customer using CSS for load balancing data center traffic. They have never been able to use SSL Session ID for session persistence (sticky). One reason is that some applications open multiple connections, each with a unique SSL Session ID, and the load balancer has no mechanism to associate these streams as part of the same client application. The other reason is that both clients and servers can renegotiate the SSL session, which changes the SSL Session ID. Modern versions of MSFT IE automatically renegotiate every two minutes, for example, and session sticky can be lost when that occurs.
You may have several options here. If you can terminate the client's SSL session on the CSM then initiate a new SSL session to the server, that will give you a chance to insert a cookie or similar that you can use for persistence. You need to understand how SSL is being used with the application. If the application is using SSL for client authentication and authorization, then you cannot terminate the SSL session on the CSM. That would constitute a man-in-the-middle, which SSL is designed to prevent. Applications can be modified to work around a load balancer terminating SSL, but that is another discussion.
Alternatively you can maintain persistence using src/dest IP addresses. That is the direction I took with my customer.
