質問: 「openssl s_client」を使用してサーバーのssl / tls証明書を取得する 以下を使用して、ロードバランサーの1つ(netscaler)のssl/tls証明書を取得しようとしています。openssl s_client -showcerts -connect lb.example.com:443 ただし、証明書は表示されません。connected(00000003) write:errno=54 -servername lb.example.comを使用しても効果がなく、システム管理者から、ロードバランサーはsniを使用しないと言われました。編集:サーバーはイントラネット上にあり、公衆インターネットからの接続を受け入れません。これは-debugを指定したopensslの出力です。connected(00000003) write to 0x7fec7af0abf0 [0x7fec7b803a00] (130 bytes => 130 (0x82)) 0000 - 80 80 01 03 01 00 57 00-00 00 20 00 00 39 00 00 ......w... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............ 0020 - 00 00 33 00 00 32 00 00-2f 00 00 9a 00 00 99 00 ..3..2../....... 0030 - 00 96 03 00 80 00 00 05-00 00 04 01 00 80 00 00 ................ 0040 - 15 00 00 12 00 00 09 06-00 40 00 00 14 00 00 11 .........@...... 0050 - 00 00 08 00 00 06 04 00-80 00 00 03 02 00 80 00 ................ 0060 - 00 ff a6 f7 27 1a a7 18-85 cf b2 03 22 fc 48 3d ....'.......".h= 0070 - dd a9 2c b7 76 67 62 80-df 85 ed 48 35 c7 d4 87 ..,.vgb....h5... 0080 - 8d d3 .. read from 0x7fec7af0abf0 [0x7fec7b809000] (7 bytes => -1 (0xffffffffffffffff)) write:errno=54 そして、これはcurl -v https://lb.example.com/からの関連出力です:$ curl -vi https://lb.exmple.com/ * trying 1.2.3.4... * connected to lb.exmple.com (10.1.2.3) port 443 (#0) * tls 1.2 connection using tls_rsa_with_aes_256_cbc_sha * server certificate: lb.example.com * server certificate: rapidssl sha256 ca - g2 * server certificate: geotrust primary certification authority - g3 > head / http/1.1 > host: lb.exmple.com > user-agent: curl/7.43.0 > accept: */* > openssl s_clientを使用して証明書を取得する方法に関する提案はありますか?
回答: 以下を使用して、ロードバランサーの1つ(netscaler)のssl/tls証明書を取得しようとしています。 openssl s_client -showcerts -connect lb.example.com:443 最新の構成(それが何を意味するかを放棄している人もいる)の場合は、次のようにします。openssl s_client -connect lb.example.com:443 -tls1 -servername lb.example.com | \ openssl x509 -text -noout connected(00000003) write to 0x7fec7af0abf0 [0x7fec7b803a00] (130 bytes => 130 (0x82)) 0000 - 80 80 01 03 01 00 57 00-00 00 20 00 00 39 00 00 ... バイト0と1に追加のプリアンブルがあるようです。バイト2にレコードタイプが必要です。バイト3と4にはバージョン番号が必要です。バイト5および6は、ペイロードの16ビット長である必要があります。これが実際の例です:$ openssl s_client -connect www.googl.com:443 -tls1 -servername www.googl.com -debug connected(00000005) write to 0x7f7fe1c1fa30 [0x7f7fe2022000] (132 bytes => 132 (0x84)) 0000 - 16 03 01 00 7f 01 00 00-7b 03 01 71 c0 12 35 98 ... 上記から、レコードタイプは位置0にあり、その値は0x16です。 0x16はハンドシェイクタイプです。レコードレイヤーのバージョンは、位置2および3の次の2バイトです。それらの値は0x03 0x01です。ペイロードの長さは0x007fです。18ページの rfc 5246、the transport layer security(tls)protocol version 1.2 も参照してください。6.2.1. fragmentation the record layer fragments information blocks into tlsplaintext records carrying data in chunks of 2^14 bytes or less. client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same contenttype may be coalesced into a single tlsplaintext record, or a single message may be fragmented across several records). struct { uint8 major; uint8 minor; } protocolversion; enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } contenttype; struct { contenttype type; protocolversion version; uint16 length; opaque fragment[tlsplaintext.length]; } tlsplaintext; 問題は、古いsslv2互換のレコードタイプである可能性があります。または、たとえば0.9.5または0.9.8のopensslのダウンレベルバージョンである可能性があります。言うのは難しいので、おそらくもっと情報が必要です。詳細にはosが含まれます。 opensslバージョン。プラットフォームのバージョンのopensslを独自のバージョンのopensslに置き換えようとした場合。ファイアウォールまたは「web検査」ボックスまたはその他のミドルウェア機能が実行されている場合。サーバーが受け取るもの。 -servername lb.example.comを使用しても効果がなく、システム管理者から、ロードバランサーはsniを使用しないと言われました。 これはちょっと珍しいですね。ただし、これはtlsの拡張機能であるため、使用しない場合は無視されます(致命的なアラートは生成されません)。2016年の経験則:常にtls 1.0以上を使用し、常にsniを使用します。