2017-08-04 35 views
1

現在、HTTPプロトコルで実行されているアプリケーションがあります。私たちはHTTPSへの移行を目指しています。私たちは必要な変更を加えましたが、アプリケーションへのログイン中に「ピアが認証されていません」というエラーメッセージが表示されます。「証明書が不明」のSSLハンドシェイクが失敗する

私は、SSLの世界に完全に新しいです、と私はアップGoogleとWiresharkのトレースをキャプチャしているとの通信は、以下のようになります。

  1. クライアントがサーバに[SYN]を送信します。
  2. サーバは[SYN、ACK]をクライアントに送信します。
  3. クライアントはサーバーに[ACK]を送信します。
  4. クライアントは、「Client Hello」というメッセージをサーバーに送信します。
  5. サーバーは、「サーバーハロー、証明書、サーバーハロードーン」というメッセージとともに公開鍵を送信します。
  6. アラート61、レベル致命、説明:証明書が不明//ここで失敗します。

入力が間違っている可能性についてご教示ください。私たちはここで立ち往生し、さらに進むことはできません。

+0

wiresharkトレースのスクリーンショットを追加して、アラートの送信元(クライアントまたはサーバー)がわかるようにしてください。 –

+0

おそらく、クライアントがサーバー証明書の署名に使用されたルート証明機関を知らない、または信頼しないため、クライアントがサーバーの証明書を検証できないように思えます。ルート権限はクライアントに知られている必要があります。そうでない場合は、クライアントは証明書の検証を無効にする必要があります(セキュリティには不向きです)。 –

+0

クライアントにサーバーセキュリティ証明書をインポートすると、この問題が解決されます。私たちは3つの異なるクライアントでこれを試しました。これは何か意味ですか?なぜサーバーに所属する証明書をクライアントにインストールする必要がありますか。 – Pavan

答えて

-1

これは奇妙なエラーで更新しました。 Certificate Unknownは通常なくのアラートコードが添付されなければなりません。

あなたが表示される場合は、SSL警告61がトレースを見ずに​​

enum { 
     close_notify(0), 
     unexpected_message(10), 
     bad_record_mac(20), 
     decryption_failed_RESERVED(21), 
     record_overflow(22), 
     decompression_failure(30), 
     handshake_failure(40), 
     no_certificate_RESERVED(41), 
     bad_certificate(42), 
     unsupported_certificate(43), 
     certificate_revoked(44), 
     certificate_expired(45), 
     certificate_unknown(46), 
     illegal_parameter(47), 
     unknown_ca(48), 
     access_denied(49), 
     decode_error(50), 
     decrypt_error(51), 
     export_restriction_RESERVED(60), 
     protocol_version(70), 
     insufficient_security(71), 
     internal_error(80), 
     user_canceled(90), 
     no_renegotiation(100), 
     unsupported_extension(110), 
     (255) 
    } AlertDescription; 

で言及されていない、さらに調査することは困難です。

サーバ証明書で提供されているように見えますサーバはクライアントによって信頼されていません。

私は-vオプションでcURL.exeを使用してこれをテストすることをお勧めします。

+0

クライアント証明書の提供に失敗したことは、TLSでは実際にはエラーではなく、ここでは発生していません。サーバーはServerHelloDoneにしかアクセスできませんでした。サーバーがクライアント証明書を必要とし、クライアント証明書を取得しない場合は、それを続行するか、handshake_failureアラートを送信します。これは、クライアントが信頼できない証明書、または間違ったタイプの証明書を送信するためのTLSプロトコル違反です。 – EJP

+0

さて、ここでは起こっていないようです。ただし、クライアント証明書を提供できないと、ハンドシェイクが失敗する可能性があります。これはやはり依存しており、現時点では何が起こったのかを本当に確かめるためにネットワークトレースを見ていません。また、61は私が期待したものではありません。しかし、私は混乱を避けるためにそれを削除するために投稿を編集します。 –

+0

クライアントにサーバーセキュリティ証明書をインポートすると、この問題が解決されます。私たちは3つの異なるクライアントでこれを試しました。これは何か意味ですか?なぜサーバーに所属する証明書をクライアントにインストールする必要がありますか。 – Pavan

関連する問題