Поломка рукостискання могла статися через різні причини:
- Несумісні шифрові пакети, якими користуються клієнт і сервер. Це вимагає від клієнта використання (або включення) набору шифрів, який підтримується сервером.
- Несумісні версії SSL у використанні (сервер може приймати тільки TLS v1, тоді як клієнт може використовувати тільки SSL v3). Знову ж, клієнту, можливо, доведеться використовувати сумісну версію протоколу SSL / TLS.
- Неповний шлях довіри для сертифіката сервера; сертифікату сервера, ймовірно, клієнт не довіряє. Зазвичай це призведе до більш детальної помилки, але це цілком можливо. Зазвичай виправлення полягає в імпорті сертифікату CA сервера в сховище клієнта.
- Сертифікат видається для іншого домену. Знову ж таки, це призвело б до більш детального повідомлення, але я викладу тут виправлення у випадку, якщо це причина. У цьому випадку рішення дозволить серверу (він, здається, не є вашим), використовувати правильний сертифікат.
Оскільки базовий збій неможливо визначити, краще включити -Djavax.net.debug=all
прапор, щоб увімкнути налагодження встановленого SSL-з'єднання. Увімкнувши налагодження, ви можете точно визначити, яка діяльність в рукостисканні не вдалася.
Оновлення
Виходячи з наявних зараз деталей, виявляється, що проблема пов’язана з неповним довірчим шляхом довіри між сертифікатом, виданим сервером, і кореневим CA. У більшості випадків це відбувається через те, що кореневий сертифікат CA відсутній у сховищі довіри, що призводить до ситуації, коли шлях довіри сертифіката не може існувати; сертифікат по суті не є довіреним клієнтом. Браузери можуть подавати попередження, щоб користувачі могли проігнорувати це, але те ж саме не стосується клієнтів SSL (наприклад, клас HttpsURLConnection або будь-яка бібліотека клієнтів HTTP, наприклад Apache HttpComponents Client ).
Більшість цих класів / бібліотек клієнтів покладаються на сховище довіри, яке використовує JVM для перевірки сертифікатів. У більшості випадків це cacerts
файл у каталозі JRE_HOME / lib / security. Якщо розташування довіреного магазину було вказано за допомогою властивості системи JVM javax.net.ssl.trustStore
, то зберігання на цьому шляху зазвичай є тим, що використовується клієнтською бібліотекою. Якщо ви сумніваєтесь, погляньте на свій Merchant
клас та з’ясуйте клас / бібліотеку, яку він використовує для встановлення з'єднання.
Додавання сервера, що видає сертифікат сервера, до цього довіреного магазину, має вирішити проблему. Ви можете звернутися до моєї відповіді на пов'язане питання щодо отримання інструментів для цієї мети, але для цієї мети достатньо утиліти Java keytool .
Попередження : Магазин довіри - це, по суті, перелік усіх ЦП, яким Ви довіряєте. Якщо ви помістите сертифікат, який не належить до ЦС, якому ви не довіряєте, то з'єднання SSL / TLS до сайтів, що мають сертифікати, видані цією особою, можуть бути розшифровані, якщо приватний ключ доступний.
Оновлення №2: Розуміння результату трасування JSSE
Магазин брелоків і довірені магазини, якими користується JVM, зазвичай перераховані на самому початку, дещо як наступне:
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
Якщо використовується неправильна сховище довіри, вам потрібно буде повторно імпортувати сертифікат сервера на потрібний або перенастроїти сервер, щоб використовувати вказаний (не рекомендується, якщо у вас кілька JVM, і всі вони використовуються для різних потреби).
Якщо ви хочете перевірити, чи містить список довірених сертифікатів потрібні серти, то для них є розділ, який починається з:
adding as trusted cert:
Subject: CN=blah, O=blah, C=blah
Issuer: CN=biggerblah, O=biggerblah, C=biggerblah
Algorithm: RSA; Serial number: yadda
Valid from SomeDate until SomeDate
Вам потрібно буде шукати, чи є ЦС сервера предметом.
Процес рукостискання матиме кілька чітких записів (вам потрібно знати SSL, щоб їх детально зрозуміти, але для налагодження поточної проблеми достатньо знати, що рукостискання_файлу зазвичай повідомляється в ServerHello.
1. КлієнтЗдрастуйте
Під час ініціалізації з'єднання буде повідомлено про ряд записів. Перше повідомлення, надіслане клієнтом у налаштуваннях з'єднання SSL / TLS, - це повідомлення ClientHello, яке зазвичай повідомляється в журналах як:
*** ClientHello, TLSv1
RandomCookie: GMT: 1291302508 bytes = { some byte array }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
***
Зверніть увагу на використовувані набір шифрів. Це, можливо, доведеться погодитись із записом у вашому файлі merchant.properties, оскільки ця ж конвенція може бути використана бібліотекою банку. Якщо застосовувана конвенція відрізняється, немає ніяких причин для занепокоєння, оскільки ServerHello зазначатиме так, якщо пакет шифрів несумісний.
2. СерверHello
Сервер відповідає за допомогою ServerHello, який вказуватиме, чи може продовжуватися налаштування з'єднання. Записи в журналах зазвичай бувають такого типу:
*** ServerHello, TLSv1
RandomCookie: GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***
Зверніть увагу на шифр, який він вибрав; найкраще це доступний як для сервера, так і для клієнта. Зазвичай шифр не задається, якщо є помилка. Сертифікат сервера (і, можливо, всієї ланцюга) надсилається сервером, і він буде знайдений у записах як:
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
Signature Algorithm: SHA1withRSA, OID = some identifer
.... the rest of the certificate
***
Якщо перевірка сертифіката вдалася, ви знайдете запис, подібний до:
Found trusted certificate:
[
[
Version: V1
Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
Signature Algorithm: SHA1withRSA, OID = some identifier
Один з перерахованих вище кроків не вдався б, внаслідок чого рукостискання_файл, оскільки рукостискання на цій стадії зазвичай завершено (не дуже, але наступні етапи рукостискання зазвичай не викликають зриву рукостискання). Вам потрібно буде з'ясувати, який крок не вдався, і опублікувати відповідне повідомлення як оновлення питання (якщо ви вже не зрозуміли повідомлення, і не знаєте, що робити для його вирішення).