【安全课堂】openssl系列篇之openssl简介

openssl简介

                                            下一篇： Openssl以及证书认证

                                             上一篇：  Openssl 常用命令

openssl简介－证书

证书就是数字化的文件，里面有一个实体(网站，个人等)的公共密钥和其他的属性，如名称等。该公共密钥只属于某一个特定的实体，它的作用是防止一个实体假装成另外一个实体。

    证书用来保证不对称加密算法的合理性。想想吧，如果没有证书记录，那么假设某俩人A与B的通话过程如下：

    这里假设A的publickey是K1, private key是K2

             B的public key是K3, private key是K4
   
    xxxxxx(kn)表示用kn加密过的一段文字xxxxxx
   
     A-----〉hello(plaintext)-------------〉B
   
     A〈---------hello(plain text)〈---------B
   
     A〈---------Bs public key〈------------B
   
     A---------〉s publickey(K1)--------〉B
   
     ... ...
        如果C想假装成B, 那么步骤就和上面一样。
   
     A-----〉hello(plaintext)-------------〉C
   
     A〈---------hello(plain text)〈---------C
   
     注意下一步，因为A没有怀疑C的身份，所以他理所当然的接受了C的
   
     public key,并且使用这个key来继续下面的通信。
   
     A〈---------Cs public key〈------------C
   
     A---------〉As publickey(K1)--------〉C
   
     ... ...
      这样的情况下A是没有办法发觉C是假的。如果A在通话过程中要求取得B的证书，并且验证证书里面记录的名字，如果名字和B的名字不符合，就可以发现对方不是B.验证B的名字通过再从证书里面提取B的公用密钥，继续通信过程。

      那么，如果证书是假的怎么办？或者证书被修改过了怎么办？慢慢看下来吧。

     证书最简单的形式就是只包含有证书拥有者的名字和公用密钥。当然现在用的证书没这么简单，里面至少还有证书过期的deadline, 颁发证书的机构名称，证书系列号，和一些其他可选的信息。最重要的是，它包含了证书颁发机构(certification authorit简称CA)的签名信息。

    我们现在常用的证书是采用X.509结构的，这是一个国际标准证书结构。任何遵循该标准的应用程序都可以读写X509结构的证书。

     通过检查证书里面的CA的名字，和CA的签名，就知道这个证书的确是由该CA签发的，然后，你就可以检查证书里面的接收证书者的名字，然后提取公共密钥。这样做建立的基础是，你信任该CA, 认为该CA没有颁发错误的证书。

    CA是第三方机构，被你信任，由它保证证书的签发给了应该得到该证书的人。CA自己有一个庞大的public key数据库，用来颁发给不同的实体。

    这里有必要解释一下，CA也是一个实体，它也有自己的公共密钥和私有密钥，否则怎么做数字签名？它也有自己的证书，你可以去它的站点down它的证书得到它的公共密钥。

    一般CA的证书都内嵌在应用程序中间。不信你打开你的IE, 在internet选项里面选中"内容", 点击"证书",看看那个"中间证书发行机构"和"委托根目录发行机构", 是不是有一大堆CA的名称？也有时CA的证书放在安全的数据库里面。

    当你接受到对方的证书的时候，你首先会去看该证书的CA, 然后去查找自己的CA证书数据库，看看是否找的到，找不到就表示自己不信任该CA, 那么就告吹本次连接。找到了的话就用该CA的证书里面的公用密钥去检查CA在证书上的签名。

    这里又有个连环的问题，我怎么知道那个CA的证书是属于那个CA的？人家不能造假吗？

    解释一下吧。CA也是分级别的。最高级别的CA叫Root CAs, 其他cheap一点的CA的证书由他们来颁发和签名。这样的话，最后的保证就是：我们信任Root CAs.那些有Root CAs签名过的证书的CA就可以来颁发证书给实体或者其他CA了。

    你不信任Root CAs?人民币由某公司发行，运到各个大银行，再运到地方银行，你从地方银行取人民币的时候不信任发行它的某公司吗？Root CAs都是很权威的机构，没有必要担心他们的信用。

    那Root CAs谁给签名?他们自己给自己签名, 叫自签名.

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

    Certificate Example
    Certificate:
    Data:
    Version: 1 (0x0)
    Serial Number: // 系列号
    02:41:00:00:16
    Signature Algorithm: md2WithRSAEncryption //CA同志的数字签名的算法
    Issuer: C=US, O=RSA Data Security, Inc., OU=Commercial//CA自报家门
    Certification
    Authority
    Validity
    Not Before: Nov 4 18:58:34 2010 GMT //证书的有效期
    Not After : Nov 3 18:58:34 2012 GMT
    Subject: C=US, O=RSA Data Security, Inc., OU=Commercial
    Certification Authority
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (1000 bit)
    Modulus (1000 bit):
    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)
    Signature Algorithm: 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

    其实这是我们看的懂的格式的证书内容，真正的证书都是加密过了的，其丑恶面容如下：
        -----BEGIN CERTIFICATE-----
   
    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
    -----END CERTIFICATE-----

    证书都是有寿命的。就是上面的那个NotBefore和NotAfter之间的日子。过期的证书，如果没有特殊原因，都要摆在证书回收列(certificaterevocation list)里面.证书回收列，英文缩写是CRL.比如一个证书的key已经被破了，或者证书拥有者没有权力再使用该证书，该证书就要考虑作废。CRL详细记录了所有作废的证书。

    CRL的缺省格式是PEM格式。当然也可以输出成我们可以读的文本格式。下面有个CRL的例子。
      
    -----BEGIN X509 CRL-----     
    MIICjTCCAfowDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAeBgNVBAoT   
    F1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2VydmVy   
    IENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw05NTA1MDIwMjEyMjZaFw05NTA2MDEw   
    MDAxNDlaMIIBaDAWAgUCQQAABBcNOTUwMjAxMTcyNDI2WjAWAgUCQQAACRcNOTUw   
    MjEwMDIxNjM5WjAWAgUCQQAADxcNOTUwMjI0MDAxMjQ5WjAWAgUCQQAADBcNOTUw   
    MjI1MDA0NjQ0WjAWAgUCQQAAGxcNOTUwMzEzMTg0MDQ5WjAWAgUCQQAAFhcNOTUw   
    MzE1MTkxNjU0WjAWAgUCQQAAGhcNOTUwMzE1MTk0MDQxWjAWAgUCQQAAHxcNOTUw   
    MzI0MTk0NDMzWjAWAgUCcgAABRcNOTUwMzI5MjAwNzExWjAWAgUCcgAAERcNOTUw   
    MzMwMDIzNDI2WjAWAgUCQQAAIBcNOTUwNDA3MDExMzIxWjAWAgUCcgAAHhcNOTUw   
    NDA4MDAwMjU5WjAWAgUCcgAAQRcNOTUwNDI4MTcxNzI0WjAWAgUCcgAAOBcNOTUw   
    NDI4MTcyNzIxWjAWAgUCcgAATBcNOTUwNTAyMDIxMjI2WjANBgkqhkiG9w0BAQIF   
    AAN+AHqOEJXSDejYy0UwxxrH/9+N2z5xu/if0J6qQmK92W0hW158wpJg+ovV3+wQ   
    wvIEPRL2rocL0tKfAsVq1IawSJzSNgxG0lrcla3MrJBnZ4GaZDu4FutZh72MR3Gt   
    JaAL3iTJHJD55kK2D/VoyY1djlsPuNh6AEgdVwFAyp0v   
    -----END X509 CRL-----

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

    The following is an example of a CRL in text format:   
    issuer= /C=US/O=RSA Data Security, Inc./OU=SecureServer Certification     
    Authority     
    lastUpdate=May 2 02:12:26 1995 GMT   
    nextUpdate=Jun 1 00:01:49 1995 GMT   
    revoked: serialNumber=027200004C revocationDate=May 202:12:26 1995 GMT     
    revoked: serialNumber=0272000038 revocationDate=Apr 2817:27:21 1995 GMT     
    revoked: serialNumber=0272000041 revocationDate=Apr 2817:17:24 1995 GMT     
    revoked: serialNumber=027200001E revocationDate=Apr 800:02:59 1995 GMT     
    revoked: serialNumber=0241000020 revocationDate=Apr 701:13:21 1995 GMT     
    revoked: serialNumber=0272000011 revocationDate=Mar 3002:34:26 1995 GMT     
    revoked: serialNumber=0272000005 revocationDate=Mar 2920:07:11 1995 GMT     
    revoked: serialNumber=024100001F revocationDate=Mar 2419:44:33 1995 GMT     
    revoked: serialNumber=024100001A revocationDate=Mar 1519:40:41 1995 GMT     
    revoked: serialNumber=0241000016 revocationDate=Mar 1519:16:54 1995 GMT     
    revoked: serialNumber=024100001B revocationDate=Mar 1318:40:49 1995 GMT     
    revoked: serialNumber=024100000C revocationDate=Feb 2500:46:44 1995 GMT     
    revoked: serialNumber=024100000F revocationDate=Feb 24 00:12:491995 GMT     
    revoked: serialNumber=0241000009 revocationDate=Feb 1002:16:39 1995 GMT     
    revoked: serialNumber=0241000004 revocationDate=Feb 117:24:26 1995 GMT     

   
    总结一下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： 这是仅能使用在sslsession renegotiation阶段的一种方式。什么是SSL sessionrenegotiation?以后的章节再解释。我英文差点，觉得这个词组也很难翻译成相应的中文。以后的文章里，我觉得很难直接翻译的单词或词组，都会直接用英文写出来。如果不是用这个模式的话,那么在regegotiation的时候，client都要把自己的证书送给server, 然后做一番分析。这个过程很消耗cpu时间的，而这个模式则不需要client在regotiation的时候重复送自己的证书了。

openssl简介－加密算法

要理解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的公共密钥。
    公共密钥和私有密钥的特点是，经过其中任何一把加密过的明文，只能用另外一把才能够解开。也就是说经过KEY_A1加密过的明文，只有KEY_A2才能够解密，反之亦然。

通信过程如下：
   
     A-------->KEY_A2------------>B
   
     A<--------KEY_B2<------------A
   
    这个过程叫做公共密钥交换，老外管这叫key exchange.
    之后A和B就分别用对方的公共密钥加密，用自己的私有密钥解密。

    一般公共密钥是要发布出去的，然后你通过自己的私有密钥加密明文，人家用你的公共密钥解密，如果能解开，那么说明你是加密人，这就是SSL使用的验证机制。

    常用的不对称加密一般有RSA, DSA, DH等。我们一般使用RSA.

    数字签名也是不对称加密算法的一个重要应用，理解它对于理解SSL很重要的，放在这里一起介绍一下。

    签名是什么大家都很熟悉吧？证明该东西是你写的，是你发布的，你就用签名搞定。看看那些重要文件都要头头签名。数字签名就是数字化的签名了。记得公用密钥和私有密钥的特征吗？只有你一个人有你自己的私有密钥。而你的公用密钥是其他人都知道的 了。那么你在写完一封邮件之后，用自己的私有密钥加密自己的名字，接收人用你的公共密钥解开一看，哦，是你发的。这就是你的数字签名过程了。

    上面的解释是很简化的了，其实数字签名比这个复杂多了，但我们没有了解的必要，知道数字签名是这么一回事就可以了。

    还有一种我们需要知道的加密算法，其实我不觉得那是加密算法 ，应该叫哈希算法，英文是message digest, 是用来把任何长度的一串明文以一定规则变成固定长度的一串字符串。它在SSL中的作用也很重要，以后会慢慢提及的。一般使用的是MD5, SHA. base64不是加密算法，但也是SSL经常使用的一种算法，它是编码方式，用来把asc码 和二进制码转来转去的。

    具体的加密解密过程我们不需要了解，因为SSL根本不关心。但了解加密算法的一些基本原理是必要的，否则很难理解SSL。

    对加密算法的细节有兴趣的同志，可以去网络上找这些加密算法的原理的文章和实现的程序来研究，不过先学数论吧。不懂数论看那玩意还是一头雾水。

openssl简介－协议

SSL(Secure Socket Layer)是netscape公司提出的主要用于web的安全通信标准,分为2.0版和3.0版.TLS(Transport Layer Security)是IETF的TLS工作组在SSL3.0基础之上提出的安全通信标准,目前版本是1.0,即RFC2246.SSL/TLS提供的安全机制可以保证应用层数据在互联网络传输不被监听,伪造和窜改.

    一般情况下的网络协议应用中，数据在机器中经过简单的由上到下的几次包装，就进入网络，如果这些包被截获的话，那么可以很容易的根据网络协议得到里面的数据.由网络监听工具可以很容易的做到这一点。

    SSL就是为了加密这些数据而产生的协议，可以这么理解，它是位与应用层和TCP/IP之间的一层，数据经过它流出的时候被加密，再往TCP/IP送，而数据从TCP/IP流入之后先进入它这一层被解密，同时它也能够验证网络连接俩端的身份。

    它的主要功能就是两个：

    一：加密解密在网络中传输的数据包, 同时保护这些数据不被修改, 和伪造。

    二：验证网络对话中双方的身份

    SSL协议包含俩个子协议，一个是包协议，一个是握手协议。包协议是说明SSL的数据包应该如何封装的。握手协议则是说明通信双方如何协商共同决定使用什么算法以及算法使用的key。 很明显包协议位于握手协议更下一层。我们暂时对包协议的内容没有兴趣。

    SSL握手过程说简单点就是：通信双方通过不对称加密算法来协商好一个对称加密算法以及使用的key, 然后用这个算法加密以后所有的数据完成应用层协议的数据交换。  

  
     握手一般都是由client发起的，SSL也不例外。

    1 client送给server它自己本身使用的ssl的version(ssl一共有三个version),加密算法的一些配置，和一些随机产生的数据，以及其他在SSL协议中需要用到的信息。

    2 server送给client它自己的SSL的version, 加密算法的配置，随机产生的数据，还会用自己的私有密钥加密SERVER-HELLO信息。Server还同时把自己的证书文件给送过去。同时有个可选的项目，就是server可以要求需要客户的certificate。

    3 client就用server送过来的certificate来验证server的身份。如果server身份验证没通过，本次通信结束。通过证书验证之后，得到server的公共密钥，解开server送来的被其用私有密钥加密过的SERVER-HELLO信息，看看对头与否。如果不对，说明对方只有该server的公共密钥而没有私有密钥，必是假的。通信告吹。

    4 client使用到目前为止所有产生了的随机数据(sharedsecret), client产生本次握手中的premaster secret(这个步骤是有可能有server的参与的，由他们使用的加密算法决定),并且把这个用server的公共密钥加密，送回给server.如果server要求需要验 证client,那么client也需要自己把自己的证书送过去，同时送一些自己签过名的数据过去。

    SSL协议有俩种技术来产生shared secret(真不好意思，又是一个很难意译的词组),一种是RSA, 一种是EDH.

    RSA就是我们上一章说过的一种不对称加密算法。首先server把自己的RSA公共密钥送给client, client于是用这个key加密一个随机产生的值(这个随机产生的值就是shared secret)， 再把结果送给server.

    EDH也是一种不对称加密算法， 但它与RSA不同的是，它好象没有自己固定的公共密 钥和私有密钥，都是在程序跑起来的时候产生的，用完就K掉。其他的步骤俩者就差不多了。

    RSA, DSA, DH三种不对称加密算法的区别也就在这里。RSA的密钥固定，后俩个需要一个参数来临时生成key.DH甚至要求双方使用同样的参数，这个参数要事先指定。如果SSL库没有load进这个参数，DH算法就没办法用。DSA没研究过。

    5 Server验证完client的身份之后，然后用自己的私有密钥解密得到premaster secret然后双方利用这个premaster secret来共同协商，得到master secret.

    6 双方用master一起产生真正的session key, 着就是他们在剩下的过程中的对称加密的key了。这个key还可以用来验证数据完整性。双方再交换结束信息。握手结束。

    接下来双方就可以用协商好的算法和key来用对称加密算法继续下面的过程了。
   

openssl简介－入门

实现了SSL的软件不多，但都蛮优秀的。首先，netscape自己提出来的概念，当然自己会实现一套了。netscape的技术蛮优秀的，不过我没用过他们的ssl-toolkit.甚至连名字都没搞清楚。

    1995年，eric.young开始开发openssl, 那时候叫ssleay.一直到现在，openssl还在不停的修改和新版本的发行之中。openssl真够大的，我真佩服eric的水平和兴趣。这些open/free的斗士的精神是我写这个系列的主要动力，虽然写的挺烦的。

ps: eric现在去了RSA公司做，做了一个叫SSL-C的toolkit, 其实和openssl差不多。估计应该比openssl稳定，区别是这个是要银子的，而且几乎所有低层的函数都不提供直接调用了。那多没意思。

    注意： 我估计openssl最开始是在linux下开发的。大家可以看一看在linux下有这么一个文件：/dev/urandom。这个文件有什么用？你可以随时找它要一个随机数。在加密算法产生key的时候，我们需要一颗种子：seed。这个seed就是找/dev/urandom要的那个随机数。那么在sparc下，由于没有这么一个设备，很多openssl的函数会报错："PRNG not seeded". 解决方法是：在你的~/.profile里面添加一个变量$RANDFILE， 设置如下：

    $RANDFILE=$HOME/.rnd

    然后在$HOME下vi .rnd, 随便往里面乱输入一些字符，起码俩行。

    很多openssl的函数都会把这个文件当seed, 除了openssl rsa, 希望openssl尽快修改这个bug.

    如果用openssl做toolkit编程， 则有其他不太安全的解决方法。以后讲到openssl编程的章节会详细介绍。

    先生成自己的私有密钥文件，比如叫server.key
    openssl genrsa -des3 -out server.key 1024

    genras表示生成RSA私有密钥文件，-des3表示用DES3加密该文件，1024是我们的key的长度。一般用512就可以了，784可用于商业行为了，1024可以用于*用途了。

    当然，这是基于现在的计算机的速度而言，可能没过几年1024是用于开发测试，2048用于一般用途了。

    生成server.key的时候会要你输入一个密码，这个密钥用来保护你的server.key文件，这样即使人家偷走你的server.key文件，也打不开，拿不到你的私有密钥。

    openssl rsa -noout -text -in server.key
    可以用来看看这个key文件里面到底有些什么东西(不过还是看不懂)

    如果你觉得server.key的保护密码太麻烦想去掉的话：
    openssl rsa -in server.key -out server.key.unsecure
    不过不推荐这么做
   

下一步要得到证书了。得到证书之前我们要生成一个Certificate Signing Request.

    CA只对CSR进行处理。

    openssl req -new -key server.key -out server.csr

    生成CSR的时候屏幕上将有提示,依照其指示一步一步输入要求的信息即可.

    生成的csr文件交给CA签名后形成服务端自己的证书.怎么交给CA签名？
     推荐：www.verisign.com   慢慢看吧。
   
    如果是自己玩下，那么自己来做CA吧。openssl有很简单的方法做CA.但一般只好在开发的时候或者自己玩的时候用，真的做出产品，还是使用正规的CA签发给你的证书吧

    在你make install之后，会发现有个misc的目录，进去，运行CA.sh -newca，他会找你要CA需要的一个CA自己的私有密钥密码文件。没有这个文件？按回车创建，输入密码来保护这个密码文件。之后会要你的一个公司信息来做CA.crt文件。最后在当前目录下多了一个./demoCA这样的目录../demoCA/private/cakey.pem就是CA的key文件啦..

    ./demoCA/cacert.pem就是CA的crt文件了。把自己创建出来的server.crt文件copy到misc目录下，mv成newreq.pem,然后执行CA.sh -sign, ok,

    得到回来的证书我们命名为server.crt.
   
    看看我们的证书里面有些什么吧

    openssl x509 -noout -text -in server.crt

    玩是玩过了，openssl的指令繁多，就象天上的星星。大家慢慢学习！

学习了~

期待。。。。。。。