使用“ openssl s_client”获取服务器的SSL / TLS证书

我正在尝试使用以下方式为我们的负载均衡器之一（Netscaler）获取SSL / TLS证书：

openssl s_client -showcerts -connect lb.example.com:443

但这不会向我显示证书：

CONNECTED(00000003)
write:errno=54

使用-servername lb.example.com无济于事，我们的系统管理员告诉我我们的负载平衡器始终不使用SNI。

编辑：服务器在我们的Intranet上，不接受来自公共Internet的连接。这是openssl的输出，其中包含-debug：

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？

过了一会儿，我发现：这个特定的负载均衡器配置为仅使用TLSv1.2，OS X（0.9.8）中包含的openssl版本不了解。我使用自制软件安装了更新版本的openssl（> = 1.0.1），因此可以正常工作：

/usr/local/opt/openssl/bin/openssl s_client -showcerts -connect lb.example.com:443

我正在尝试使用以下方式为我们的负载均衡器之一（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的下两个字节。它们的值是0x03 0x01。有效载荷的长度为0x007f。

另请参阅RFC 5246，传输层安全性（TLS）协议版本1.2，第18页：

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兼容记录类型。或者它可能是OpenSSL的较低版本，例如0.9.5或0.9.8。很难说，我们可能需要更多信息。

更多信息将包括操作系统；OpenSSL版本；如果您尝试用自己的OpenSSL版本替换平台的OpenSSL版本；是否有防火墙或“网络检查”框或其他中间件运行？以及服务器收到的内容。

使用-servername lb.example.com无济于事，我们的系统管理员告诉我我们的负载平衡器始终不使用SNI。

这听起来很不正常。但是它是TLS的扩展，因此如果不使用它，则将其忽略（并且不会产生致命警报）。

2016年的经验法则：始终使用TLS 1.0或更高版本，并始终使用SNI。