承認のために証明書が必要なサービスに接続しようとしています。プロセスは、サービスにCSRファイルを送信することです。サービスはCSRに署名し、接続に使用する証明書を送信します。
次のコマンドラインでCSRを生成しました。
openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr
cert.csrの内容を取得して送信しました。彼らはクライアント証明書を生成し、私はPEMファイルを取り戻しました。
ここで、curl（）用にSSLCERTの証明書ファイルを使用して接続し、cert.keyからの秘密鍵をCURLOPT_SSLKEYとして提供しようとしています-（手順1で取得しました）。
失敗する： error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
このプロセスで何が間違っているのですか？
サービスから秘密鍵を含む受信したテスト証明書（自己署名証明書）を試してみると機能します。しかし、CSRから生成された証明書を使用してから、秘密鍵を鍵として使用すると、ハンドシェイクの失敗でエラーが発生します。
したがって、openssl / curlがv3 / TLSなどをサポートしていないこととは関係がないことを私は知っています。他の人が解決策を研究しているときに、問題があったことがわかりました。
これが私が実行するものです：
curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure
* Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0
次のバージョンを実行しています：curl 7.35.0（x86_64-pc-linux-gnu）libcurl / 7.35.0 OpenSSL / 1.0.1f zlib / 1.2.8 libidn / 1.28 librtmp / 2.3
明確な答えではありませんが、コメントに収まらないほどです。
私は、彼らがあなたに間違った発行者（彼らのサーバーはそれに対してより具体的なアラートコードを使用する可能性がありますが）または間違った件名を持っている証明書を与えたと仮定します。私たちは、証明書は、あなたのPrivateKeyと一致して知っている-の両方があるためcurlとopenssl client不一致文句なしでそれらをペアリング。ただし、実際には、目的のCAと一致するかどうかはわかりません。curlはopensslとopensslを使用しているため、SSLクライアントは構成済みのクライアント証明書がcertreq.CAと一致することを強制しません。
やるopenssl x509 <clientcert.pem -noout -subject -issuer働くテストP12からの証明書に同じ。実行openssl s_client（または実行したものを確認）して、以下を確認しますAcceptable client certificate CA names。そこにある名前またはそれらの1つは、証明書の発行者と（正確に！）一致する必要があります。そうでない場合は、それが問題である可能性が高く、CSRを正しい場所に正しい方法で提出したことを彼らに確認する必要があります。おそらく、彼らは異なる地域、ビジネスライン、テストと製品、アクティブと保留などで異なる体制を持っています。
証明書の発行者がdesiredCAと一致する場合は、そのサブジェクトを機能している（test-P12）ものと比較します。それらは同様の形式ですか？動作中のコンポーネントに、あなたのコンポーネントに存在しないコンポーネントはありますか？許可されている場合は、test-P12とまったく同じ、またはできるだけ近いサブジェクト名で新しいCSRを生成して送信し、それによってより適切に機能する証明書が生成されるかどうかを確認してください。（これを行うために新しいキーを生成する必要はありませんが、必要に応じて、どの証明書がどのキーと一致するかを追跡して、それらが混同されないようにします。）それでも証明書を確認するのに役立たない場合openssl x509 <cert -noout -textKeyUsage、ExtendedKeyUsage、ポリシー、制約、さらには非標準など、サブジェクトの承認に合理的に関連する可能性のある違いがある拡張機能。
他のすべてが失敗した場合は、サーバーオペレーターに問題についてログが何を言っているかを尋ねるか、アクセスできる場合は自分でログを確認してください。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加