Comments 13
Вы точно не ошиблись? Заказчик выдал вам приватный ключ от своего ssl-сертификата?
Не ошиблась. Аутентификация же двухстронняя)
Не от своего ssl-сертификата, а от клиентского
Для клиентского приложения сгенерировали пару: приватный ключ и сертификат (в составе которого, соответственно, публичный ключ), и выдали мне.
Этот сертификат установили на сервере в списке доверенных. Приватный ключ, как водится, только на стороне клиентского приложения хранится
Не от своего ssl-сертификата, а от клиентского
Для клиентского приложения сгенерировали пару: приватный ключ и сертификат (в составе которого, соответственно, публичный ключ), и выдали мне.
Этот сертификат установили на сервере в списке доверенных. Приватный ключ, как водится, только на стороне клиентского приложения хранится
Исчерпывающий ответ. Здорово.
В 80% приватный ключ для аутентификации генерирует сам владелец сервера. Потому что 99% клиентов вообще не понимают, что это и для чего оно нужно.
В 80% приватный ключ для аутентификации генерирует сам владелец сервера. Потому что 99% клиентов вообще не понимают, что это и для чего оно нужно.
Вот в этом вся и беда! При этом не только ключ аутентификации, но ключевая пара при получении на УЦ сертификата электронной плдписи и т.д.
А, я понял, ключ для вашего приложения. Спасибо.
Спасибо за статью, было приятно осознать, что кто-то сталкивался с такого же рода ошибкой ура, я не один. Правда, дело было в dotnet, но суть точно такая же, как ни странно. При чем тем же курлом оправдывались – работает же!
Взаимно)
А вы каким образом докопались до root cause?
А вы каким образом докопались до root cause?
У меня скорее была проблема из-за ограниченного API предоставляемого дотнетом, – по итогу ключ не добавлялся в контейнер, а из-за этого сервер выдавал 500 ошибку. Даже не добавлялся, а просто API нет такого, чтобы обеспечить генерацию .pfx/pkcs12 из пары cert/key в PEM формате.
Решил прямым использованием OpenSSL враппера и созданием контейнера собственноручно.
Решил прямым использованием OpenSSL враппера и созданием контейнера собственноручно.
у меня была немного другая ситуация… необходимо было переписать SOAP-клиент на новую яву (и в принципе сервлет-сервис переписать). так у меня рукопожатие не заканчивалось, уже не помню… с моей стороны отвал что ли (а проблема из-за того, что начиная с JDK 1.7.0_25 вроде, ужесточилась политика безопасности). Ключ с сертификатом в контейнер добавлялся так же как и для старой версии, но цепочка в контейнере не находилась по итогу. Пришлось прикручивать HostnameVerifier и использовать собственный SSLSocketFactory и X509KeyManager и только тогда вся цепочка проверялась и соединение устанавливалось.
Работа с сертификатами SSL в java это боль.
очень сумбурно написано…
Sign up to leave a comment.
История одного SSL рукопожатия