Сегодняшний день был богат на новую информацию. Например, настраивая обмен данными по платежам по ssl, получила невиданную доселе ошибку handshake failure.
Коллега, который такую ошибку уже видел, предположил несоответсвие версий протокола, но его действия по исправлению этого косяка ни к чему не привели. И, пока он ходил за консультацией к разработчику, я нагуглила следующее по теме:
The handshake failure could have occurred due to various reasons:
Incompatible cipher suites in use by the client and the server. This would require the client to use (or enable) a cipher suite that is supported by the server.
Incompatible versions of SSL in use (the server might accept only TLS v1, while the client is capable of only using SSL v3). Again, the client might have to ensure that it uses a compatible version of the SSL/TLS protocol.
Incomplete trust path for the server certificate; the server's certificate is probably not trusted by the client. This would usually result in a more verbose error, but it is quite possible. Usually the fix is to import the server's CA certificate into the client's trust store.
The cerificate is issued for a different domain. Again, this would have resulted in a more verbose message, but I'll state the fix here in case this is the cause. The resolution in this case would be get the server (it does not appear to be yours) to use the correct certificate.
Since, the underlying failure cannot be pinpointed, it is better to switch on the -Djavax.net.debug=all flag to enable debugging of the SSL connection established. With the debug switched on, you can pinpoint what activity in the handshake has failed.
Собственно, чтение лога после включения дебага и делалось, но корень ошибки все равно был не очевиден.
Однако, все оказалось банальным до нельзя - я просто накосячила, добавив не тот сетификат в контейнер (клиент несколько раз менял урл с сертификатом, и в моем распоряжении их была порядочная кучка %)).
План на завтра - вкуривание настройки по подписанию файлов КриптоПро.