OpenSSL+命令翻译.docx

OpenSSL+命令翻译.docx

《OpenSSL+命令翻译.docx》由会员分享，可在线阅读，更多相关《OpenSSL+命令翻译.docx（81页珍藏版）》请在冰豆网上搜索。

OpenSSL+命令翻译

OpenSSL

1.标题:

openssl简介--前言2

2.标题penssl简介--证书2

3.标题penssl简介--加密算法7

4.标题penssl简介--协议9

5.openssl简介－入门11

6.OpenSSL指令12

6.1.openssl简介－指令verify12

6.2.openssl简介－指令asn1parse16

6.3.openssl简介－指令ca17

6.4.openssl简介－指令cipher22

6.5.openssl简介－指令dgst27

6.6.openssl简介－指令dhparam28

6.7.openssl简介－指令enc29

6.8.openssl简介－指令gendsa32

6.9.openssl简介－指令genrsa32

6.10.openssl简介－指令passwd33

6.11.openssl简介－指令pkcs734

6.12.openssl简介－指令rand35

6.13.openssl简介－指令req35

6.14.openssl简介－指令rsa40

6.15.openssl简介－指令rsautl42

6.16.openssl简介－指令s_client44

6.17.openssl简介－指令s_server50

6.18.openssl简介－指令sess_id52

6.19.openssl简介－指令speed53

6.20.openssl简介－指令version53

6.21.openssl简介－指令x50954

1.标题:

openssl简介--前言

发信站:

BBS水木清华站（FriNov1020:

24:

102000）

引用请指明原作/译者fordesign@

不久前接到有关ssl的活，结果找遍中文网站资料实在奇缺。

感觉是好象现在国内做这个技术的人不多所有有兴趣写点东西来介绍一下。

我使用的ssl的toolkit是openssl就用openssl做例子来讲解

openssl实在太大了，指令也多，API也多，更严重的是它的API没有说明。

我打算漫漫说清楚其主要指令的用法，主要API的中文说明，以及使用/编程的方法。

工作量很大，因为我接触它也没几个月，现在大概完成了1/10吧，先把目前自己的一些心得，找到的资料和一些翻译出来的东西贴出来，希望对研究ssl的人有帮助

2.标题penssl简介--证书

证书就是数字化的文件，里面有一个实体（网站，个人等）的公共密钥和其他的属性，如名称等。

该公共密钥只属于某一个特定的实体，它的作用是防止一个实体假装成另外一个实体。

证书用来保证不对称加密算法的合理性。

想想吧，如果没有证书记录，那么假设某俩人A与B的通话过程如下：

这里假设A的publickey是K1,privatekey是K2，B的publickey是K3,privatekey是K4

xxxxxx（kn）表示用kn加密过的一段文字xxxxxx

A-----〉hello（plaintext）-------------〉B

A〈---------hello（plaintext）〈---------B

A〈---------Bspublickey〈------------B

A---------〉spublickey（K1）--------〉B

......

如果C想假装成B,那么步骤就和上面一样。

A-----〉hello（plaintext）-------------〉C

A〈---------hello（plaintext）〈---------C

注意下一步，因为A没有怀疑C的身份，所以他理所当然的接受了C的publickey,并且使用这个key来继续下面的通信。

A〈---------Cspublickey〈------------C

A---------〉Aspublickey（K1）--------〉C

......

这样的情况下A是没有办法发觉C是假的。

如果A在通话过程中要求取得B的证书，并且验证证书里面记录的名字，如果名字和B的名字不符合，就可以发现对方不是B.验证B的名字通过再从证书里面提取B的公用密钥，继续通信过程。

那么，如果证书是假的怎么办？

或者证书被修改过了怎么办？

慢慢看下来吧。

证书最简单的形式就是只包含有证书拥有者的名字和公用密钥。

当然现在用的证书没这么简单，里面至少还有证书过期的deadline,颁发证书的机构名称，证书系列号，和一些其他可选的信息。

最重要的是，它包含了证书颁发机构（certificationauthority简称CA）的签名信息。

我们现在常用的证书是采用X.509结构的，这是一个国际标准证书结构。

任何遵循该标准的应用程序都可以读，写X509结构的证书。

通过检查证书里面的CA的名字，和CA的签名，就知道这个证书的确是由该CA签发的然后，你就可以简单证书里面的接收证书者的名字，然后提取公共密钥。

这样做建立的基础是，你信任该CA,认为该CA没有颁发错误的证书。

CA是第三方机构，被你信任，由它保证证书的确发给了应该得到该证书的人。

CA自己有一个庞大的publickey数据库，用来颁发给不同的实体。

这里有必要解释一下，CA也是一个实体，它也有自己的公共密钥和私有密钥，否则怎么做数字签名？

它也有自己的证书，你可以去它的站点down它的证书得到它的公共密钥。

一般CA的证书都内嵌在应用程序中间。

不信你打开你的IE,在internet选项里面选中"内容",点击"证书",看看那个"中间证书发行机构"和"委托根目录发行机构",是不是有一大堆CA的名称？

也有时CA的证书放在安全的数据库里面。

当你接受到对方的证书的时候，你首先会去看该证书的CA,然后去查找自己的CA证书数据库，看看是否找的到，找不到就表示自己不信任该CA,那么就告吹本次连接。

找到了的话就用该CA的证书里面的公用密钥去检查CA在证书上的签名。

这里又有个连环的问题，我怎么知道那个CA的证书是属于那个CA的？

人家不能造假吗？

解释一下吧。

CA也是分级别的。

最高级别的CA叫RootCAs,其他cheap一点的CA的证书由他们来颁发和签名。

这样的话，最后的保证就是：

我们信任RootCAs.那些有RootCAs签名过的证书的CA就可以来颁发证书给实体或者其他CA了。

你不信任RootCAs?

人民币由中国人民银行发行，运到各个大银行，再运到地方银行，你从地方银行取人民币的时候不信任发行它的中国人民银行吗？

RootCAs都是很权威的机构，没有必要担心他们的信用。

那RootCAs谁给签名?

他们自己给自己签名,叫自签名.

说了这么多，举个certificate的例子吧,对一些必要的item解释一下。

CertificateExample

Certificate:

Data:

Version:

1（0x0）

SerialNumber:

//系列号

02:

41:

00:

00:

16

SignatureAlgorithm:

md2WithRSAEncryption//CA同志的数字签名的算法

Issuer:

C=US,O=RSADataSecurity,Inc.,OU=Commercial//CA自报家门

Certification

Authority

Validity

NotBefore:

Nov418:

58:

341994GMT//证书的有效期

NotAfter:

Nov318:

58:

341999GMT

Subject:

C=US,O=RSADataSecurity,Inc.,OU=Commercial

CertificationAuthority

SubjectPublicKeyInfo:

PublicKeyAlgorithm:

rsaEncryption

RSAPublicKey1000bit）

Modulus（1000bit）:

00:

a4:

fb:

81:

62:

7b:

ce:

10:

27:

dd:

e8:

f7:

be:

6c:

6e:

c6:

70:

99:

db:

b8:

d5:

05:

03:

69:

28:

82:

9c:

72:

7f:

96:

3f:

8e:

ec:

ac:

29:

92:

3f:

8a:

14:

f8:

42:

76:

be:

bd:

5d:

03:

b9:

90:

d4:

d0:

bc:

06:

b2:

51:

33:

5f:

c4:

c2:

bf:

b6:

8b:

8f:

99:

b6:

62:

22:

60:

dd:

db:

df:

20:

82:

b4:

ca:

a2:

2f:

2d:

50:

ed:

94:

32:

de:

e0:

55:

8d:

d4:

68:

e2:

e0:

4c:

d2:

cd:

05:

16:

2e:

95:

66:

5c:

61:

52:

38:

1e:

51:

a8:

82:

a1:

c4:

ef:

25:

e9:

0a:

e6:

8b:

2b:

8e:

31:

66:

d9:

f8:

d9:

fd:

bd:

3b:

69:

d9:

eb

Exponent:

65537（0x10001）

SignatureAlgorithm:

md2WithRSAEncryption

76:

b5:

b6:

10:

fe:

23:

f7:

f7:

59:

62:

4b:

b0:

5f:

9c:

c1:

68:

bc:

49:

bb:

b3:

49:

6f:

21:

47:

5d:

2b:

9d:

54:

c4:

00:

28:

3f:

98:

b9:

f2:

8a:

83:

9b:

60:

7f:

eb:

50:

c7:

ab:

05:

10:

2d:

3d:

ed:

38:

02:

c1:

a5:

48:

d2:

fe:

65:

a0:

c0:

bc:

ea:

a6:

23:

16:

66:

6c:

1b:

24:

a9:

f3:

ec:

79:

35:

18:

4f:

26:

c8:

e3:

af:

50:

4a:

c7:

a7:

31:

6b:

d0:

7c:

18:

9d:

50:

bf:

a9:

26:

fa:

26:

2b:

46:

9c:

14:

a9:

bb:

5b:

30:

98:

42:

28:

b5:

4b:

53:

bb:

43:

09:

92:

40:

ba:

a8:

aa:

5a:

a4:

c6:

b6:

8b:

57:

4d:

c5

其实这是我们看的懂的格式的证书内容，真正的证书都是加密过了的，如下：

-----BEGINCERTIFICATE-----

MIIDcTCCAtqgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBiDELMAkGA1UEBhMCQ0gx

EjAQBgNVBAgTCWd1YW5nZG9uZzESMBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQK

Ewhhc2lhaW5mbzELMAkGA1UECxMCc3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZI

hvcNAQkBFhJmb3JkZXNpZ25AMjFjbi5jb20wHhcNMDAwODMwMDc0MTU1WhcNMDEw

ODMwMDc0MTU1WjCBiDELMAkGA1UEBhMCQ0gxEjAQBgNVBAgTCWd1YW5nZG9uZzES

MBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQKEwhhc2lhaW5mbzELMAkGA1UECxMC

c3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZIhvcNAQkBFhJmb3JkZXNpZ25AMjFj

bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMDYArTAhLIFacYZwP30

Zu63mAkgpAjVHaIsIEJ6wySIZl2THEHjJ0kS3i8lyMqcl7dUFcAXlLYi2+rdktoG

jBQMOtOHv1/cmo0vzuf38+NrAZSZT9ZweJfIlp8W9uyz8Dv5hekQgXFg/l3L+HSx

wNvQalaOEw2nyf45/np/QhNpAgMBAAGjgegwgeUwHQYDVR0OBBYEFKBL7xGeHQSm

ICH5wBrOiqNFiildMIG1BgNVHSMEga0wgaqAFKBL7xGeHQSmICH5wBrOiqNFiild

oYGOpIGLMIGIMQswCQYDVQQGEwJDSDESMBAGA1UECBMJZ3Vhbmdkb25nMRIwEAYD

VQQHEwlndWFuZ3pob3UxETAPBgNVBAoTCGFzaWFpbmZvMQswCQYDVQQLEwJzdzEO

MAwGA1UEAxMFaGVucnkxITAfBgkqhkiG9w0BCQEWEmZvcmRlc2lnbkAyMWNuLmNv

bYIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAGQa9HK2mixM7ML7

0jZr1QJUHrBoabX2AbDchb4Lt3qAgPOktTc3F+K7NgB3WSVbdqC9r3YpS23RexU1

aFcHihDn73s+PfhVjpT8arC1RQDg9bDPvUUYphdQC0U+HF72/CvxGCTqpnWiqsgw

xqeog0A8H3doDrffw8Zb7408+Iqf

-----ENDCERTIFICATE-----

证书都是有寿命的。

就是上面的那个NotBefore和NotAfter之间的日子。

过期的证书，如果没有特殊原因，都要摆在证书回收列（certificaterevocationlist）里面.证书回收列，英文缩写是CRL.比如一个证书的key已经被破了，或者证书拥有者没有权力再使用该证书，该证书就要考虑作废。

CRL详细记录了所有作废的证书。

CRL的缺省格式是PEM格式。

当然也可以输出成我们可以读的文本格式。

下面有个CRL的例子。

-----BEGINX509CRL-----

MIICjTCCAfowDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAeBgNVBAoT

F1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2VydmVy

IENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw05NTA1MDIwMjEyMjZaFw05NTA2MDEw

MDAxNDlaMIIBaDAWAgUCQQAABBcNOTUwMjAxMTcyNDI2WjAWAgUCQQAACRcNOTUw

MjEwMDIxNjM5WjAWAgUCQQAADxcNOTUwMjI0MDAxMjQ5WjAWAgUCQQAADBcNOTUw

MjI1MDA0NjQ0WjAWAgUCQQAAGxcNOTUwMzEzMTg0MDQ5WjAWAgUCQQAAFhcNOTUw

MzE1MTkxNjU0WjAWAgUCQQAAGhcNOTUwMzE1MTk0MDQxWjAWAgUCQQAAHxcNOTUw

MzI0MTk0NDMzWjAWAgUCcgAABRcNOTUwMzI5MjAwNzExWjAWAgUCcgAAERcNOTUw

MzMwMDIzNDI2WjAWAgUCQQAAIBcNOTUwNDA3MDExMzIxWjAWAgUCcgAAHhcNOTUw

NDA4MDAwMjU5WjAWAgUCcgAAQRcNOTUwNDI4MTcxNzI0WjAWAgUCcgAAOBcNOTUw

NDI4MTcyNzIxWjAWAgUCcgAATBcNOTUwNTAyMDIxMjI2WjANBgkqhkiG9w0BAQIF

AAN+AHqOEJXSDejYy0UwxxrH/9+N2z5xu/if0J6qQmK92W0hW158wpJg+ovV3+wQ

wvIEPRL2rocL0tKfAsVq1IawSJzSNgxG0lrcla3MrJBnZ4GaZDu4FutZh72MR3Gt

JaAL3iTJHJD55kK2D/VoyY1djlsPuNh6AEgdVwFAyp0v

-----ENDX509CRL-----

下面是文本格式的CRL的例子。

ThefollowingisanexampleofaCRLintextformat:

issuer=/C=US/O=RSADataSecurity,Inc./OU=SecureServerCertification

Authority

lastUpdate=May202:

12:

261995GMT

nextUpdate=Jun100:

01:

491995GMT

revoked:

serialNumber=027200004CrevocationDate=May202:

12:

261995GMT

revoked:

serialNumber=0272000038revocationDate=Apr2817:

27:

211995GMT

revoked:

serialNumber=0272000041revocationDate=Apr2817:

17:

241995GMT

revoked:

serialNumber=027200001ErevocationDate=Apr800:

02:

591995GMT

revoked:

serialNumber=0241000020revocationDate=Apr701:

13:

211995GMT

revoked:

serialNumber=0272000011revocationDate=Mar3002:

34:

261995GMT

revoked:

serialNumber=0272000005revocationDate=Mar2920:

07:

111995GMT

revoked:

serialNumber=024100001FrevocationDate=Mar2419:

44:

331995GMT

revoked:

serialNumber=024100001ArevocationDate=Mar1519:

40:

411995GMT

revoked:

serialNumber=0241000016revocationDate=Mar1519:

16:

541995GMT

revoked:

serialNumber=024100001BrevocationDate=Mar1318:

40:

491995GMT

revoked:

serialNumber=024100000CrevocationDate=Feb2500:

46:

441995GMT

revoked:

serialNumber=024100000FrevocationDate=Feb2400:

12:

491995GMT

revoked:

serialNumber=0241000009revocationDate=Feb1002:

16:

391995GMT

revoked:

serialNumber=0241000004revocationDate=Feb117:

24:

261995GMT

总结一下X.509证书是个什么东东吧。

它实际上是建立了公共密钥和某个实体之间联系的数字化的文件。

它包含的内容有：

版本信息,X.509也是有三个版本的。

系列号

证书接受者名称

颁发者名称

证书有效期

公共密钥

一大堆的可选的其他信息

CA的数字签名

证书由CA颁发，由CA决定该证书的有效期，由该CA签名。

每个证书都有唯一的系列号。

证书的系列号和证书颁发者来决定某证书的唯一身份。

openssl有四个验证证书的模式。

你还可以指定一个callback函数，在验证证书的时候会自动调用该callback函数。

这样可以自己根据验证结果来决定应用程序的行为。

具体的东西在以后的章节会详细介绍的。

openssl的四个验证证书模式分别是：

SSL_VERIFY_NONE:

完全忽略验证证书的结果。

当你觉得握手必须完成的话，就选用这个选项。

其实真正有证书的人很少,尤其在中国。

那么如果SSL运用于一些免费的服务，比如email的时候，我觉得server端最好采用这个模式。

SSL_VERIFY_PEER:

希望验证对方的证书。

不用说这个是最一般的模式了.对client来说，如果设置了这样的模式，验证server的证书出了任何错误，SSL握手都告吹.对server来说,如果设置了这样的模式,client倒不一定要把自己的证书交出去。

如果client没有交出证书，server自己决定下一步怎么做。

SSL_VERIFY_FAIL_IF_NO_PEER_CERT:

这是server使用的一种模式，在这种模式下，server会向client要证书。

如果client不给，SSL握手告吹。

SSL_VERIFY_CLIENT_ONCE：

这是仅能使用在sslsessionrenegotiation阶段的一种方式。

什么是SSLsessionrenegotiation?

以后的章节再解释。

我英文差点，觉得这个词组也很难翻译成相应的中文。

以后的文章里，我觉得很难直接翻译的单词或词组，都会直接用英文写出来。

如果不是用这个模式的话,那么在regegotiation的时候，client都要把自己的证书送给server,然后做一番分析。

这个过程很消耗cpu时间的，而这个模式则不需要client在regotiation的时候重复送自己的证书了。

3.标题penssl简介--加密算法

要理解ssl先要知道一些加密算法的常识.

加密算法很容易理解啦，就是把明文变成人家看不懂的东西，然后送给自己想要的送到的地方，接收方用配套的解密算法又把密文解开成明文，这样就不怕在路世上如果密文给人家截获而泄密。

加密算法有俩大类，第一种是不基于KEY的，举个简单的例子，我要加密"fordesign"这么一串字符，就把每个字符都变成它的后一个字符，那么就是"gpseftjhm"了，这样的东西人家当然看不明白，接收方用相反的方法就可以得到原文。

当然这只是个例子，现在应该没人用这么搞笑的加密算法了吧。

不基于KEY的加密算法好象一直用到了计算机出现。

我记得古中国军事机密都是用这种方式加密的。

打战的时候好象军队那些电报员也要带着密码本，也应该是用这种方式加密的。

这种算法的安全性以保持算法的保密为前提。

这种加密算法的缺点太明显了，就是一旦你的加密算法给人家知道，就肯定挂。

日本中途岛惨败好象就是密码给老米破了。

设计一种算法是很麻烦的，一旦给人破了就没用了，这也忑浪费。

我们现在使用的加密算法一般是基于key的，也就是说在加密过程中需要一个key,用这个key来对明文进行加密。

这样的算法即使一次被破，下次改个key,还可以继续用。

key是一个什么东西呢？

随便你，可以是一个随机产生的数字，或者一个单词，啥都行，只要你用的算法认为你选来做key的那玩意合法就行。

这样的算法最重要的是：

其安全性取决于key,一般来说取决于key的长度。

也就是说应该保证人家在知道这个算法而不知道key的情况下，破解也相当困难。

其实现在常用的基于KEY的加密算法在网络上都可以找到，很多革命同志（都是老外）都在想办法破解基于key的加密算法又包括俩类：

对称加密和不对称加密。

对称加密指的是双方使用完全相同的key，最常见的是DES.DES3,RC4等。

对称加密算法的原理很容易理解，通信一方用KEK加密明文，另一方收到之后用同样的KEY来解密就可以得到明文。

不对称加密指双方用不同的KEY加密和解密明文，通信双方都要有自己的公共密钥和私有密钥。

举个例子比较容易理解，我们们假设通信双方分别是A,B.

A,拥有KEY_A1,KEY_A2,其中KEY_A1是A的私有密钥，KEY_A2是A的公共密钥。

B,拥有KEY_B1,KEY_B2,其中KEY_B1是B的私有密钥，KEY_B2是B的公共密钥。

公共密钥和私有密钥的特点是，经过其中任何一把加密过的明文，只能用另外一把才能够解开。

也就