TLS с сертификатом клиента при сбое рукопожатия - PullRequest
0 голосов
/ 25 сентября 2018

Я не совсем понимаю, где именно мне нужно включить сертификат клиента.Теперь моя первая проблема - я не доверяю серверу.Я попытался использовать файл хранилища ключей Java по умолчанию (cacerts), в котором есть и Thawte, и Digicert, и это корневые права доступа сервера, с которым я пытаюсь установить связь.Я установил этот файл cacerts как хранилище ключей, используя System.setProperty("javax.net.ssl.keyStore", "..."), он не работал, я установил его как хранилище доверенных сертификатов, он не работал.Я все еще получил

, не в состоянии найти действительный путь сертификации для запрошенной цели

Так что я временно разобрался, используя AlwaysTrustSSLConnectionFactory().

. ТеперьПроблема в том, что сервер не доверяет мне.У меня есть сертификат клиента, и я попытался добавить его в хранилище ключей и хранилище доверенных сертификатов, но независимо от того, что я делаю, после ServerHelloDone я получаю

Предупреждение: подходящий сертификат не найден - продолжение без проверки подлинности клиента

в сообщениях отладки SSL Java и сбое рукопожатия после секретных и ключевых сообщений.Вот конец моего журнала:

http-bio-8080-exec-3, READ: TLSv1.2 Handshake, length = 333
*** ECDH ServerKeyExchange
Signature Algorithm SHA512withRSA
Server key: Sun EC public key, 256 bits
  public x coord: 98538070232466209510508111485778316025052762596580196398964623226311407167077
  public y coord: 115064641147496698382202313215933439469086519002181671334211217988795069727259
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
http-bio-8080-exec-3, READ: TLSv1.2 Handshake, length = 117
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, SHA256withDSA, SHA256withECDSA, Unknown (hash:0x3, signature:0x1), Unknown (hash:0x3, signature:0x2), Unknown (hash:0x3, signature:0x3), SHA1withRSA, SHA1withDSA, SHA1withECDSA
Cert Authorities:
<CN=test, O=test>
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>
***
*** ECDHClientKeyExchange
ECDH Public value:  { 4, 27, 38, 123, 80, 37, 162, 101, 222, 228, 249, 225, 170, 123, 245, 118, 154, 198, 134, 128, 105, 222, 20, 31, 183, 237, 163, 35, 13, 205, 219, 241, 43, 132, 49, 107, 207, 71, 25, 241, 130, 82, 194, 153, 140, 243, 105, 178, 174, 151, 108, 57, 63, 166, 138, 93, 70, 56, 244, 199, 166, 104, 183, 4, 78 }
http-bio-8080-exec-3, WRITE: TLSv1.2 Handshake, length = 77
SESSION KEYGEN:
PreMaster Secret:
0000: 6E 2D CC 68 0D 92 38 2F   67 B8 D7 C8 3B 72 8B 65  n-.h..8/g...;r.e
0010: 82 04 4B 63 67 38 BB D3   96 ED 1A 49 61 11 7B E2  ..Kcg8.....Ia...
CONNECTION KEYGEN:
Client Nonce:
0000: 5B A9 E3 1C 95 8B 8A 3A   D2 F7 65 7B DC 34 53 0E  [......:..e..4S.
0010: AC 24 4C AE 95 F9 EF 27   1F F1 1F 11 0E 05 E8 1E  .$L....'........
Server Nonce:
0000: 11 DE 45 EB B6 63 F1 7B   DF E6 DC A8 34 85 D4 07  ..E..c......4...
0010: FE 61 EB CB 5D CA 3D D9   5B 26 56 B0 60 61 A4 9E  .a..].=.[&V.`a..
Master Secret:
0000: 4B 47 2B E9 84 38 18 D7   F2 A9 81 6B 3B 12 B9 FB  KG+..8.....k;...
0010: 18 D5 30 C9 9A 11 C5 D5   C8 5B 91 03 00 08 B1 F4  ..0......[......
0020: CD D7 56 6C 9A 80 1C 85   BD 7C 9A DF 40 9F AE 64  ..Vl........@..d
... no MAC keys used for this cipher
Client write key:
0000: F7 E3 C7 06 53 55 06 35   84 71 42 FA F7 0A AD ED  ....SU.5.qB.....
0010: F4 AE B4 BD 79 C7 79 FD   F5 84 F7 48 42 0D 6F 10  ....y.y....HB.o.
Server write key:
0000: 98 95 3F DB C6 E6 DC 4C   4B 03 F6 FF E4 C6 C1 28  ..?....LK......(
0010: F4 08 C9 29 C2 2F 25 4F   4E 1D 7A 0D 74 F0 1C FC  ...)./%ON.z.t...
Client write IV:
0000: 5B FA EF 63                                        [..c
Server write IV:
0000: 36 72 AE 18                                        6r..
http-bio-8080-exec-3, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 255, 41, 51, 7, 96, 87, 163, 245, 51, 86, 110, 34 }
***
http-bio-8080-exec-3, WRITE: TLSv1.2 Handshake, length = 40
http-bio-8080-exec-3, READ: TLSv1.2 Alert, length = 2
http-bio-8080-exec-3, RECV TLSv1.2 ALERT:  fatal, handshake_failure
%% Invalidated:  [Session-7, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
http-bio-8080-exec-3, called closeSocket()
http-bio-8080-exec-3, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)

Вот мой текущий код:

System.setProperty("javax.net.ssl.keyStore", "C:/Users/Lovro/Desktop/certs/api/keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "pass");

URL url = new URL(urlRequest);
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(new AlwaysTrustSSLContextFactory());
conn.connect();

Я получил сертификат клиента от разработчиков API в формате .p12, поэтому я преобразовал егона .crt и добавил это в хранилище ключей с помощью Keytool .Кто-нибудь знает, в чем может быть проблема, и мое рукопожатие терпит неудачу, потому что я не включил сертификат клиента должным образом или если я не добавил его в хранилище ключей должным образом?Насколько я понимаю, хранилище доверенных сертификатов должно содержать открытые ключи доверенных корневых прав доступа, а хранилище ключей должно иметь мой сертификат клиента.Это правильно?Как мне этого добиться?

Любые предложения приветствуются, я новичок в TLS / HTTPS и не знаю, что я делаю.

Ответы [ 2 ]

0 голосов
/ 25 сентября 2018

Я получил свой сертификат клиента от разработчиков API в формате .p12, поэтому я преобразовал его в .crt и добавил его в хранилище ключей с помощью Keytool

Здесь вы ошиблись.Преобразование его в .crt извлекает публичный сертификат.Что вам нужно сделать, это конвертировать .p12 файл в хранилище ключей Java.В сети много примеров.См. этот SO-ответ о том, как.

Чтобы убедиться, что он работает, запустите keytool -list -keystore <yourkeystore>.jks и убедитесь, что у вас есть PrivateKeyEntry.

Пока вы 'Чтобы проверить вещи, добавьте флаг -v к команде keytool -list и убедитесь, что в поле «Эмитент» указано CN=test, O=test, поскольку из вашего файла журнала видно, что вашему серверу требуется сертификат клиента, выданный этим органом.

Также убедитесь, что ваш JDK сконфигурирован с юрисдикцией неограниченной силы Файлы политик , поскольку этого требует шифр, который вас просят использовать.

0 голосов
/ 25 сентября 2018

Из журнала кажется, что шифр TLS TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 недействителен для клиента TLS.Вам может понадобиться проверить, какой клиент списка шифров поддерживает.Если шифр TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 не включен в список шифров, вам может потребоваться добавить его поддержку.

http-bio-8080-exec-3, READ: TLSv1.2 Предупреждение, длина= 2
http-bio-8080-exec-3, RECV TLSv1.2 ALERT: смертельно, рукопожатие_отказ
%% недействительно: [Session-7, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...