工具使用-tls协议相关-openss工具使用01

勇敢的星火

已于 2024-08-29 12:19:22 修改

阅读量745

点赞数 33

分类专栏： P200常见协议考究文章标签：测试工具 linux

于 2024-05-30 08:30:00 首次发布

本文链接：https://blog.csdn.net/qinaide56/article/details/139307721

版权

P200常见协议考究专栏收录该内容

12 篇文章 0 订阅

订阅专栏

参考来源：

书籍：openssl-cookbook 中文版{A.7.2 版本 1.4(2014 年 12 月 8 日)}译者：李振宇
来自openssl工具本身的帮助文档

阅读建议：
文章是关于书籍第二部分的读书笔记，可以自己阅读书籍后练习，命令执行时遇到问题再可以看到下这篇文章，当然，也可以看文章后再决定是否值得去读原文，狗头.jpg。
书籍目录

openssl版本信息查看

openssl version 查看openssl版本信息

root@ub1804:/home/xiaoyue/workdir/openssldir# openssl version
OpenSSL 1.1.1  11 Sep 2018

可以使用-a开关获取完整的版本信息

root@ub1804:/home/xiaoyue/workdir/openssldir# openssl version -a
OpenSSL 1.1.1  11 Sep 2018
built on: Wed May 24 17:14:51 2023 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-rFFxFC/openssl-1.1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

查看可用命令

openssl help

第一部分帮助列出了所有可以使用的工具。如果对于某个命令，想获取更加详细的信息，可
以使用man加上工具的名称。例如man ciphers会告诉我们密码套件是如何配置的。
帮助信息不止上面这些

Standard commands

在第二部分的帮助信息里我们可以看到可用的消息摘要命令：

Message Digest commands (see the `dgst' command for more details)

然后在第三部分的帮助信息中，我们可以看到所有的加密命令：

Cipher commands (see the `enc' command for more details)

关于openssl自带的客户端工具s_client的使用帮助

root@ub1804:/opt# openssl s_client -help
Usage: s_client [options]
Valid options are:
 -help                      Display this summary
 -host val                  Use -connect instead
 -port +int                 Use -connect instead
 -connect val               **TCP/IP where to connect (default is :4433)**
 -bind val                  bind local address for connection
 -proxy val                 Connect to via specified proxy to the real server
 -unix val                  Connect over the specified Unix-domain socket
 -4                         Use IPv4 only
 -6                         Use IPv6 only
 -verify +int               Turn on peer certificate verification
 -cert infile               Certificate file to use, PEM format assumed
 -certform PEM|DER          Certificate format (PEM or DER) PEM default
 -nameopt val               Various certificate name options
 -key val                   Private key file to use, if not in -cert file
 -keyform PEM|DER|ENGINE    Key format (PEM, DER or engine) PEM default
 -pass val                  Private key file pass phrase source
 -CApath dir                PEM format directory of CA's
 -CAfile infile             PEM format file of CA's
 -no-CAfile                 Do not load the default certificates file
 -no-CApath                 Do not load certificates from the default certificates directory
 -requestCAfile infile      PEM format file of CA names to send to the server
 -dane_tlsa_domain val      DANE TLSA base domain
 -dane_tlsa_rrdata val      DANE TLSA rrdata presentation form
 -dane_ee_no_namechecks     Disable name checks when matching DANE-EE(3) TLSA records
 -reconnect                 **Drop and re-make the connection with the same Session-ID**
 -showcerts                 **Show all certificates sent by the server**
.
.
.

文档第二部分的阅读实践记录

2.1 连接ssl服务

openssl的默认连接https端口为4433(查看s_client帮助可以看到)

openssl s_client -connect www.baidu.com:443

访问https协议下的百度首页，输出示例如下

root@ub1804:/home/xiaoyue/workdir/openssldir# openssl s_client -connect www.baidu.com:443

诊断输出的解读(四个部分)

最开始的几行显示的是服务器的证书信息。

CONNECTED(00000005)
depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
verify return:1
depth=0 C = CN, ST = beijing, L = beijing, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com
verify return:1

输出中的第二部分按照服务器交付的顺序罗列了所有证书。
每一张证书都会在第一行显示使用者信息，第二行显示颁发者信息。
这部分很重要，特别是当你需要看看到底发送了什么证书的时候；浏览器证书查看器一般都会显示重建的证书链，可能与上面呈现的会完全不一样。为了确定证书链是否正确，你可能会希望验证使用者和颁发者信息是否匹配。从最上面的分支（Web服务器）证书开始，逐级遍历列表，看看当前证书的颁发者与从属证书的使用者是否匹配。最后你看到的颁发者指向了某个不在证书链里面的根证书；或者是一个自己指向自己的根证书。

Certificate chain
 0 s:C = CN, ST = beijing, L = beijing, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com
   i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
 1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
   i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
 2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA

输出中的第三部分是服务器证书；它非常长，为了更好地呈现，我进行了简化：

如果想深入了解证书，就需要先从输出内容中复制一份并保存在单独的文件中，我会在2.2
节中具体讨论。

注意 :
任何时候当你在主题栏看到很长一串数字而不是一个名称的时候，意味着OpenSSL并不认识这个对象标识符。对象标识符是全球唯一而且是用来清楚指向某些东西的标识符。例如在前面的输出中，OID 1.3.6.1.4.1.311.60.2.1.3应该显示成jurisdiction-OfIncorporationCountryName，这个OID用于扩展验证证书

输出的第四部分是关于TLS连接的，意思从字面上就可以很容易理解了，最重要的信息是协议版本（TLS 1.1）和使用的密码套件（ECDHE-RSA-AES128-GCM-SHA256）。另外还能发现服务器返回了一个会话ID和TLS 会话票证（一种在非服务器维护状态下即可恢复会话的方式）(TLS session ticket)，而且也支持安全重新协商。一旦理解了这些输出内容所包含的信息，以后就无需再关注
它了。

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5410 bytes and written 441 bytes
Verification: OK
---
New, **TLSv1.2**, Cipher is **ECDHE-RSA-AES128-GCM-SHA256**
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    **Session-ID**: 9872EB89165693CE65B1F6830E87B3931D46E5C6BBD957BFB058F5D8B51516B7
    Session-ID-ctx: 
    Master-Key: 5E8E7AA45CE9F620411C3D32C0FBE04A90DC2B5A862FF533C3D7F27DB12CD74E899FFE00F62A8056D694A3F65DC52CB1
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    **TLS session ticket**:
    0000 - 7e 8f db 42 4d c8 55 48-7c b8 06 60 5b d8 42 3e   ~..BM.UH|..`[.B>
    0010 - 57 4a c6 8e 44 f1 e8 9a-a9 ce 0f ff 65 e5 96 60   WJ..D.......e..`
    0020 - 2e a5 d0 41 65 eb d5 bd-e9 bb 9a d6 c3 16 29 7f   ...Ae.........).
    0030 - 31 9a 2e 3f dc 24 bc d4-19 24 c8 c4 8c d7 23 81   1..?.$...$....#.
    0040 - a2 2a 0d 15 c6 ef ff 9b-3d 72 ca ad b1 61 fc 69   .*......=r...a.i
    0050 - dd 4f 98 14 6a bd 21 22-e0 34 56 32 d6 53 f3 43   .O..j.!".4V2.S.C
    0060 - fd d9 5e 8d bc d9 9d 14-8e 6c 2b af 84 19 64 58   ..^......l+...dX
    0070 - 18 02 a1 17 5e 77 98 b0-21 a0 1c a5 92 f4 33 b3   ....^w..!.....3.
    0080 - c4 5c 30 e0 23 be dc 21-7a 36 b6 d0 57 85 4b 74   .\0.#..!z6..W.Kt
    0090 - 53 93 f0 65 3d 1b 3c b0-1d 32 c5 62 63 ca cc 54   S..e=.<..2.bc..T


    Start Time: 1716966976
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

指定可信根证书路径连接

s_client不会寻找系统默认的可信证书，它会提示在证书链中存在自签名证书。在大多数情况下不用关注证书是否有效，但是如果有必要的话，可以让s_client指定可信根证书，例如：

$ openssl s_client -connect www.feistyduck.com:443 -CAfile /etc/ssl/certs/ca-certificates.crt

与之前提示的不一样，现在你可以看到它验证了证书链上每一级的证书。为了验证通过，你
必须选择好CA证书路径。我在例子中使用的路径（/etc/ssl/certs/ca-certificates.crt）

根证书内置在系统中

root@ub1804:/etc/ssl/certs# ls -l | grep "ISRG"
lrwxrwxrwx 1 root root     16 3月  22 11:52 0b9bc432.0 -> ISRG_Root_X2.pem
lrwxrwxrwx 1 root root     16 3月  20 23:40 4042bcee.0 -> ISRG_Root_X1.pem
lrwxrwxrwx 1 root root     51 3月  20 23:40 ISRG_Root_X1.pem -> /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt
lrwxrwxrwx 1 root root     51 3月  22 11:52 ISRG_Root_X2.pem -> /usr/share/ca-certificates/mozilla/ISRG_Root_X2.crt
root@ub1804:/etc/ssl/certs# pwd
/etc/ssl/certs

2.3 使用不同的握手格式

有时用OpenSSL测试服务器的时候，即便你知道服务器支持TLS（例如，使用浏览器访问的时候TLS可以正常工作），你对服务器的通信也可能会失败。其中一个可能的因素是服务器不支持老版本的SSL 握手。

如果遇到了无法正常工作的情况，而且无法准确判断是什么的话，可以强制OpenSSL
使用更新的握手格式。可以通过禁用SSL 3来实现：

$ openssl s_client -connect www.feistyduck.com:443 -no_ssl3

另外一种实现同样效果的方式是在命令行上指明要访问的主机名：
$ openssl s_client -connect www.feistyduck.com:443 -servername www.feistyduck.com
为了指明主机名，OpenSSL需要使用一种更新的握手协议里面的特性（该特性叫作服务器名称指示，server name indication或SNI），该特性会强制废弃老的格式。

2.4 提取远程证书

当使用s_client连接远程安全服务器的时候，它会将服务器的PEM编码格式证书转储到标准输出。如果需要证书的话，那么可以从回滚（scroll-back）缓冲区里面复制出来。如果提前知道你只需要获得证书的话，那么可以使用下面这个命令：

root@ub1804:/home/xiaoyue/workdir/openssldir# echo | openssl s_client -connect www.feistyduck.com:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >www.feistyduck.com.crt
root@ub1804:/home/xiaoyue/workdir/openssldir# ls
hello.de  hello.en  hello.txt  private.pem  public.pem  www.feistyduck.com.crt

最前面的echo命令的目的是将shell命令和s_client分开。如果不用echo的话，那么s_client会一直等待你的输入，直到服务器超时（可能需要很长一段时间）。
默认情况下s_client只打印分支证书；

打印完整的证书链

如果希望打印完整的证书链，请使用-showcerts开关。
使用了这个开关，前面这条命令会将所有的证书输出到同一个文件里面。

打印完整证书链，连接connect 之后添加-showcerts参数

root@ub1804:/home/xiaoyue/workdir/openssldir# echo | openssl s_client -connect  www.baidu.com:443 -showcerts 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >www.baiduallchain.com.crt

2.5 测试支持的协议

默认情况下s_client会尝试使用最高级的协议和远程服务器进行通信，并且在输出内容里面报告协商的版本信息。

示例：指定协议tls1.2连接百度，可以通过 openssl s_client -help 查看更多可以指定的协议

root@ub1804:/home/xiaoyue/workdir/openssldir# openssl s_client -connect www.baidu.com:443 -tls1_2

2.6 测试支持的密码套件（这个通过在线工具或者自动化工具实现测试)

如果你想要用OpenSSL去确定远程服务器是否支持某个特殊密码套件，这里有一个小技巧。
加密配置字符串的设计是为了选择你想要使用的套件，所以如果只指定一个套件并且与服务器握
手成功，那么就可以确定服务器支持这个套件。如果握手失败了，你就知道它并不支持。
我们以一个例子来测试一下服务器是否支持RC4-SHA算法，键入以下命令：
$ openssl s_client -connect www.feistyduck.com:443 -cipher RC4-SHA

2.7 测试要求包含 SNI 的服务器

最开始SSL和TLS协议设计的时候，每个IP端点（IP地址加端口）只支持一个网站。TLS的SNI扩展是为了在同一个IP端点上支持多张证书。TLS客户端使用这个扩展发送希望访问的主机名，
而TLS服务器使用该扩展来选择的要用以响应的正确证书。简单来说，SNI支持了虚拟安全托管。

因为很多服务器还不支持SNI，所以大部分情况下你在使用s_client的时候不需要指定主机
名。但是当你遇到启用了SNI支持的系统，就会遇到下面三种情况中的任意一种。
 大多数情况下，无论是否提供SNI信息都会获得同样的证书。
 服务器返回的证书可能是别的站点的证书，不是你想要测试的证书。
 极少情况下服务器可能会中止握手，并且拒绝连接。

你可以在s_client中使用-servername开关来启用SNI：

$ openssl s_client -connect www.feistyduck.com:443 -servername www.feistyduck.com

你可以通过使用和不使用SNI开关，并且检查证书是否相同来确定某个站点是否支持SNI。如果证书不相同，表示SNI是必需的。
有时候，如果请求的主机名不可用，服务器会返回TLS警告。即便就服务器而言，这个警告不是致命的，客户端还是可能决定关闭连接。

2.8 测试会话复用

当加上-reconnect开关的时候，s_client命令可以用来测试会话复用。在此模式下，s_client
与目标服务器连接6次，在第一次的时候会创建新的会话，然后在接下来的5次请求中复用同样的
会话：

$ echo | openssl s_client -connect www.feistyduck.com:443 -reconnect
上面这个命令会产生大量输出，大部分都无需理会。最重要的部分是新会话和复用会话的信
息。这些信息中应该只会在开头部分有一个新的会话，如下面这行：

New, TLSv1/SSLv3, Cipher is RC4-SHA
之后是5次复用的会话，如下面这样：
Reused, TLSv1/SSLv3, Cipher is RC4-SHA
大部分情况下你可能不会关心所有的输出，想要快点知道答案。那么可以使用下面这个命令：

root@ub1804:/home/xiaoyue/workdir/openssldir# echo | openssl s_client -connect www.baidu.com:443 -reconnect -no_ssl3 2> /dev/null | grep 'New\|Reused'
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256

下面是该命令的功能介绍。
 -reconnect开关激活了会话复用模式。
 -no_ssl3开关表明我们不希望使用SSL 3连接
 2> /dev/null部分将你不需要关心的标准错误隐藏掉了。
 最后，通过管道化的grep命令过滤出你关心的那几行。

注意
如果在测试会话复用的时候不想使用会话票证，例如有时候不是所有客户端都支持该
特性，可以使用-no_ticket开关禁用会话票证。

2.9 检查 OCSP 吊销状态

如果OCSP响应程序出现故障，有时候很难理解到底是为什么。用命令行检测证书吊销状态是可行的，但并不是非常直接。需要执行下面这些步骤。
(1) 获得想要检查吊销状态的证书。
(2) 获得颁发证书。
(3) 确定OCSP响应程序的URL。
(4) 提交OCSP请求并观察响应。

前面两个步骤可以在连接服务器的时候指明-showcerts开关：
$ openssl s_client -connect www.feistyduck.com:443 -showcerts
输出信息的第一张证书属于服务器证书。如果证书链的配置没错的话，第二张证书就是颁发
者的证书。为了确保没有问题，需要检查第一张证书的颁发者与第二张证书的使用者是否匹配：

如果第二张证书不对的话，需要检测证书链里剩余的证书；有些服务器配置了错误的证书链
顺序。如果无法在证书链中找到颁发者的证书，那就得去别的地方找找。

有一种方式是通过查找
分支证书的颁发机构信息访问（authority information access）扩展：【miss】
$ openssl x509 -in fd.crt -noout -text

如果看到CA颁发者（CA issuer）的信息，就应该能找到颁发者证书的URL。如果颁发者的
信息不存在，那么可以尝试在浏览器中打开这个网站，让浏览器构建整个证书链，然后从浏览器
的证书查看器里面下载颁发者的证书。如果以上所有的尝试都失败的话，可以在可信库里面进行
查找或者访问CA的网站。
如果你已经有了证书，想知道OCSP响应程序的地址，可以使用x509命令带上-ocsp_uri开关：
$ openssl x509 -in fd.crt -noout -ocsp_uri http://ocsp.starfieldtech.com/
现在可以提交OCSP请求了：
$ openssl ocsp -issuer issuer.crt -cert fd.crt -url http://ocsp.starfieldtech.com/ -CAfile issuer.crt
WARNING: no nonce in response
Response verify OK
fd.crt: good
This Update: Feb 18 17:59:10 2013 GMT
Next Update: Feb 18 23:59:10 2013 GMT

你需要在响应里面查找两个结果。
第一，检查响应自身是否有效（上面这个例子是Response Verify OK表示有效），
第二，检查响应的结果是什么。如果你看到的状态是good那么表示该证书没有被吊销，如果是revoked则表示该证书已经被吊销了。

注意
警告信息里面说的缺少nonce（加密通信中仅使用一次的密钥）的意思是OpenSSL想
要使用nonce来防止重放攻击，但是服务器的响应中并没有nonce。这种情况多数是因
为CA希望提高他们的OCSP响应程序的性能。当他们禁用了nonce保护（标准允许这
么做），OCSP响应能够被制造（一般是批量制造）、缓存并且在一段时间内重用。

你可能会遇到某些OCSP响应程序无法成功响应前面的命令。这种情况下，下面的建议可能会有所帮助。

 不要请求nonce
有些服务器无法很好地处理nonce，响应就会出错。默认情况下OpenSSL会请求一个nonce，
如果要禁用，可以通过在命令中指定-no_nonce开关。

 在请求头中提供主机名
有些HTTP请求没有在Host头中指定正确的主机名，虽然大部分的OCSP服务器都能正常响应，但也有一些不行。如果你遇到的错误里面包含HTTP错误码（例如404），那么可以尝试在OCSP请求的时候带上主机名。在OpenSSL 1.0.0以及更高版本中可以使用-header
开关，不过该开关无法在文档中查到。

有了前面这两个要点，最终可以使用下面这行命令：
$ openssl ocsp -issuer issuer.crt -cert fd.crt -url http://ocsp.starfieldtech.com/
-CAfile issuer.crt -no_nonce -header Host ocsp.starfieldtech.com

2.10 测试 OCSP stapling

OCSP stapling是一个可选特性，它允许在传输服务器证书的时候带上OCSP响应来验证证书的有效性。
因为OCSP响应是通过已经存在的连接进行传输的，所以客户端无需另外单独获取。
只有客户端在握手请求的时候提交status_request扩展，服务器才会使用OCSP stapling。服
务器如果支持OCSP stapling的话，就会在握手里面带上OCSP响应信息。
使用s_client工具带上-status 开关来请求OCSP stapling：
$ echo | openssl s_client -connect www.feistyduck.com:443 -status
OCSP相关信息会在连接输出的最开始展现出来。例如，如果服务器不支持stapling的话，在
输出的最开始部分就会看到：

root@ub1804:/home/xiaoyue/workdir/openssldir# echo | openssl s_client -connect www.feistyduck.com:443 -status
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = blog.ivanristic.com
verify return:1
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = R3
    Produced At: May 28 22:51:00 2024 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
      Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6
      Serial Number: 03C10958EB2445686F25380399A3187FE473
    **Cert Status: good**
    This Update: May 28 22:51:00 2024 GMT
    Next Update: Jun  4 22:50:58 2024 GMT

证书状态为good表示该证书未被吊销

2.11 检查 CRL 吊销状态

与OCSP相比，通过检查证书吊销列表（certificate revocation list，CRL）来检测证书有效性会更复杂，过程如下所示。
(1) 获得你想要检测吊销状态的证书。
(2) 获得颁发证书。
(3) 下载并验证CRL
(4) 在CRL列表中查找证书序列号。

第一步与OCSP检测方式一样，可以按照2.9节中的步骤实施。

CRL的地址已经编码进服务器证书，可以使用下面的命令取出：
$ openssl x509 -in fd.crt -noout -text | grep crl
URI:http://rapidssl-crl.geotrust.com/crls/rapidssl.crl

从CA获取CRL：
$ wget http://rapidssl-crl.geotrust.com/crls/rapidssl.crl

验证CRL是有效的（例如，是由颁发者的证书签名的）：
$ openssl crl -in rapidssl.crl -inform DER -CAfile issuer.crt -noout
verify OK

现在，确定希望进行检测的证书的序列号：
$ openssl x509 -in fd.crt -noout -serial
serial=0FE760

此时，可以将CRL转换成可读的的格式，然后手动检查：
$ openssl crl -in rapidssl.crl -inform DER -text -noout

在CRL的开头是一些元数据，之后是吊销证书的列表，结尾部分是签名（我们在上一步中验证过）。如果服务器证书的序列号在这份列表里面，意味着该证书已经被吊销了。
如果不想逐行寻找序列号（有一些CRL可能会很长），那就用grep查找它，但是需要小心，确保格式正确（例如，如有必要，可以移除最开始的0x，删除所有在开头的0，并且将所有字母变成大写）。例如：
$ openssl crl -in rapidssl.crl -inform DER -text -noout | grep FE760

2.12 测试重新协商

s_client工具还有几个可以协助你手动进行重新协商测试的特性。首先，当你连接的时候，
s_client会报告远程服务器是否支持重新协商。因为服务器如果支持安全重新协商的话，那么它
会在握手阶段通过交换特殊的TLS扩展来表明支持该特性。如果服务器支持，输出可能是这样的
（我已将重点加粗）：

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
**Secure Renegotiation IS supported**
Compression: NONE
Expansion: NONE
SSL-Session:
[...]

如果服务器不支持安全重新协商，输出会有一些不同：
Secure Renegotiation IS NOT supported

即便服务器表明它支持安全重新协商，你也想测试一下他是否允许客户端开始这个重新协
商。由客户端发起的重新协商（client-initiated renegotiation）是一个在实际中用不到的协议特性
（因为如果有必要的话都可以由服务器发起重新协商），该特性会使得服务器更容易受到拒绝式服
务攻击。
要开始重新协商，需要在单独一行中输入R字符。例如，假设我们正在与HTTP服务器通信，
你可以在第一行发送一个请求，初始化重新协商，然后结束请求。在向一个支持客户端发起重新
协商的Web服务器发起请求的时候，会出现以下内容：

pass

当发生了重新协商，服务器会重新将它的证书发送给客户端。你可以在输出内容中看到对证
书链的校验过程，在那之后是Host请求头。能够看到Web服务器的响应就证明服务器是支持重新
协商的。由于在不同版本的SSL/TLS库中发现了不同形式的重新协商问题，不支持重新协商的服
务器可能会直接断开连接，或者即使保持连接处于打开状态，也会拒绝在该连接上继续通信（结
果通常是超时）。

不支持重新协商的服务器会直截了当地拒绝在该连接上进行第二次握手：

pass
后面是关于一些老版本openssl已知漏洞的测试，直接跳过了。