首先先想一下下面几个问题：服务器间的相互通讯，如何保证安全？CA怎样做防伪机制？
什么是CA？
linux对通讯的要求：数据的完整性，认证安全，数据的机密性。
随机数生成器:
linux在内存当中保持一个熵池（用户两次敲键盘的时间间隔放在这个池子中，外部存储设备接收中断请求信息，两次中断的时间间隔也放在这个池子）这个池子也可能用完，在linux下生成随机数有/dev/random(这是最近的随机数生成器，所有的随机数都来于熵池，一旦熵池随机数耗尽，要等待其它事件生成随机数)
/dev/urandom（也是从熵池中取随机数，一旦熵池随机数耗尽，urandom将使用伪随机数生成器来生成随机数。）
单向加密算法：提取数据的特征码的，无论数据多大，其特征码都是定长的，单向加密还有雪崩效应特点。常见的加密算法MD5（128bit），sha1（安全的哈希算法160bit）
对称加密算法：3DES，AES双方用相同的密码加密解密通讯，能保证数据的安全性，但不能保证数据的完整性。
公钥加密算法：RSA,DSA(只能实现数字签名) 实现用户的密钥交换和数字签名
DC：数字证书： 证书包括（组织机构，邮编，公钥）
CA：在发证的时候包含组织机构，名称，地址和公钥的文件信息的时候用单向加密计算à计算校验码，然后用自己的私钥加密这个校验码。这个过程就是数字签名。
PKI：公钥基础设施：CA集合
<?xml:namespace prefix = o />
通讯双方通讯完整过程
如A和B通讯
1， A把自己的证书发给B，B通过给A发证CA的公钥去解密证书的签名信息，获得证书的特征码，然后再计算后面数据比较特征码，然后B验证A的是否为合法公钥。
2， 如果合法，B用A的公钥加密一个对称密码给个A
3， A用私钥解密，获取通讯的对称密码，
4， A先用提取出通讯文件的特征码，然后用自己的私钥加密特征码，然后用对称密码加密整个数据。
5， B先要对称密码解密整个数据，然后用A的公钥解密出来文件的特征码，然后再用单向加密提取特征码，比较特征码，保证数据完整性。
DH ：密钥交换协议。
ssl协议通讯交换过程
1， 客服端发送请求给服务端，协商共同支持的加密算法
2， 服务端发送证书给客服端
3， 客服端验证服务端
4， 客服端用双方都支持的加密算法，生成一个对称密钥，用服务端的公钥加密发个服务端
5， 服务端用私钥解密，双方协定对称密码。
linux上能够实现加密和数字签名的有：openssl 和gpg
openssl是一个工具:用一个子工具实现MD5和sha1单向加密来保证数据的完整性，openssl有三个组件：libcrypto，libssl，openssl
openssl的子命令：
[root@server75 ~]# openssl ?
openssl:Error: '?' is an invalid command.
Standard commands （标准的命令）
asn1parse ca ciphers crl crl2pkcs7
dgst （单向加密） dh dhparam dsa dsaparam
enc（实现数据加密） engine errstr gendh gendsa
genrsa （生成rsa格式的密钥对） nseq ocsp passwd （可以生产用户保存在/etc/passwd的密码） pkcs12
pkcs7 pkcs8 prime rand req （表示签署请求）
rsa rsautl s_client s_server s_time
sess_id smime speed spkac verify
version x509 （证书类型）
Message Digest commands (see the `dgst' command for more details) （信息摘要的命令）
md2 md4 md5 rmd160 sha
sha1
Cipher commands (see the `enc' command for more details) （加密的命令）
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc
aes-256-ecb base64 bf bf-cbc bf-cfb
bf-ecb bf-ofb cast cast-cbc cast5-cbc
cast5-cfb cast5-ecb cast5-ofb des des-cbc
des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb
des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx rc2 rc2-40-cbc
rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb
rc4 rc4-40
加密例子
openssl enc -des3 -salt -a -in inittab -out fstab.des3
解密
openssl enc -d -des3 -salt -a -in fstab.des3 -out fstab
单向加密例子
[root@server75 tmp]# openssl dgst -sha1 fstab
SHA1(fstab)= 78ef239097844c223671e99a79d6b533dced8d3b
生产 MD5 密码串
[root@server75 tmp]# openssl passwd -1 （一）
Password:
Verifying - Password:
$1$/CGERhoZ$SN7TQkQBG/IVB1qvu6zuz.
CA 证书颁发机构架设
如何做CA
cd /etc/pki/CA/
(umask 077; openssl genrsa 1024 > private/cakey.pem)
vim /etc/pki/tls/openssl.conf
找到 [ CA_default ]
把dir =../../CA 换成
dir=/etc/pki/CA
openssl req -new -x509 -key private/cakey.pem -out cacert.pem -days 3655
touch index.txt serial
mkdir certs newcerts crl
echo 01 > serial
客服端如何申请证书
(umask 077; openssl genrsa 1024 > www.key)
openssl req -new -key www.key -out www.csr
把CSR文件传送给CA服务器，由CA服务器签署证书：
openssl ca -in www.csr -out www.crt
然后把 www.crt 传给客户端；
SSL
SSL主要工作流程包括：网络连接建立；与该连接相关的加密方式和压缩方式选择；双方的身份识别；本次传输密钥的确定；加密的数据传输；网络连接的关闭。应用数据的传输过程为：（1）应用程序把应用数据提交给本地的SSL；（2）发送端根据需要，使用指定的压缩算法，压缩应用数据；（3）发送端使用散列算法对压缩后的数据进行散列，得到数据的散列值；（4）发送端把散列值和压缩后的应用数据一起用加密算法加密；（5）密文通过网络传给对方；（6）接收方用相同的加密算法对密文解密，得到明文；（7）接收方用相同的散列算法对明文中的应用数据散列；（8）计算得到的散列值与明文中的散列值比较；如果一致，则明文有效，接收方的SSL把明文解压后得到应用数据上交给接收方的应用。否则就丢弃数据，并向发方发出告警信息。严重的错误有可能引起再次的协商或连接中断。SSL协议建立在传输层和应用层之间，包括两个子协议：SSL记录协议和SSL握手协议，其中记录协议在握手协议下端。
SSL记录协议定义了要传输数据的格式，它位于一些可靠的的传输协议之上（如TCP），用于各种更高层协议的封装。SSL握手协议就是这样一个被封装的协议。SSL握手协议允许服务器与客户机在应用程序传输和接收数据之前互相认证、协商加密算法和密钥。 SSL 记录协议为 SSL 连接提供两种服务：机密性和报文完整性。
在 SSL 协议中，所有的传输数据都被封装在记录中。记录是由记录头和长度不为 0 的记录数据组成的。所有的 SSL 通信都使用 SSL 记录层，记录协议封装上层的握手协议、警告协议、改变密码格式协议和应用数据协议。 SSL 记录协议包括了记录头和记录数据格式的规定。主要操作： 
（1）分段每个上层应用数据被分成214字节或更小的数据块。记录中包含类型、版本号、长度和数据字段。（2）压缩压缩是可选的，并且是无损压缩，压缩后内容长度的增加不能超过1024字节。（3）在压缩数据上计算消息认证MAC。（4）对压缩数据及MAC进行加密。（5）增加SSL记录头。记录协议字段包括： 内容类型（8位）：封装的高层协议。 主要版本（8位）：使用的SSL主要版本。对于SSLv3.0，值为3。 次要版本（8位）：使用的SSL次要版本。对于SSLv3.0，值为0。 压缩长度（16位）：明文数据（如果选用压缩则是压缩数据）以字节为单位的长度
（1）分段每个上层应用数据被分成214字节或更小的数据块。记录中包含类型、版本号、长度和数据字段。（2）压缩压缩是可选的，并且是无损压缩，压缩后内容长度的增加不能超过1024字节。（3）在压缩数据上计算消息认证MAC。（4）对压缩数据及MAC进行加密。（5）增加SSL记录头。记录协议字段包括： 内容类型（8位）：封装的高层协议。 主要版本（8位）：使用的SSL主要版本。对于SSLv3.0，值为3。 次要版本（8位）：使用的SSL次要版本。对于SSLv3.0，值为0。 压缩长度（16位）：明文数据（如果选用压缩则是压缩数据）以字节为单位的长度 。
已经定义的内容类型是握手协议、警告协议、改变密码格式协议和应用数据协议。其中改变密码格式协议是最简单的协议，这个协议由值为1的单字节报文组成，用于改变连接使用的密文族。警告协议用来将SSL有关的警告传送给对方。警告协议的每个报文由两个字节组成，第一字节指明级别（1警告或2致命），第二字节指明特定警告的代码。
已经定义的内容类型是握手协议、警告协议、改变密码格式协议和应用数据协议。其中改变密码格式协议是最简单的协议，这个协议由值为1的单字节报文组成，用于改变连接使用的密文族。警告协议用来将SSL有关的警告传送给对方。警告协议的每个报文由两个字节组成，第一字节指明级别（1警告或2致命），第二字节指明特定警告的代码。 SSL握手协议被封装在记录协议中，该协议允许服务器与客户机在应用程序传输和接收数据之前互相认证、协商加密算法和密钥。在初次建立SSL连接时服务器与客户机交换一系列消息。
这些消息交换能够实现如下操作：
（1）客户机认证服务器；
（2）允许客户机与服务器选择双方都支持的密码算法；
（3）可选择的服务器认证客户；
（4）使用公钥加密技术生成共享密钥；
（5）建立加密SSL连接。
SSL握手协议报文头包括三个字段：
类型（1字节）：该字段指明使用的SSL握手协议报文类型。SSL握手协议报文包括10种类型。报文类型见图
长度（3字节）：以字节为单位的报文长度。
内容（≥1字节）：使用的报文的有关参数。
SSL握手协议的过程如下
注：带* 的传输是可选的，或者与站点相关的，并不总是发送的报文。（1）建立安全能力。客户机向服务器发送client_hello报文，服务器向客户机回应server_hello报文，建立如下的安全属性：协议版本，会话ID，密文族，压缩方法，同时生成并交换用于防止重放***的随机数。密文族参数包括密钥交换方法（Deffie-Hellman密钥交换算法、基于RSA的密钥交换和另一种实现在Fortezza chip上的密钥交换）、加密算法（DES、RC4、RC2、3DES等）、MAC算法（MD5或SHA-1）、加密类型（流或分组）等内容。
（2）认证服务器和密钥交换。在hello报文之后，如果服务器需要被认证，服务器将发送其证书。如果需要，服务器还要发送server_key_exchange。然后，服务器可以向客户发送certificate_request请求证书。服务器总是发送server_hello_done报文，指示服务器的hello阶段结束。
（3）认证客户和密钥交换。客户一旦收到服务器的server_hello_done报文，客户将检查服务器证书的合法性（如果服务器要求），如果服务器向客户请求了证书，客户必须发送客户证书，然后发送client_key_exchange报文，报文的内容依赖于client_hello与server_hello定义的密钥交换的类型。最后，客户可能发送client__verify 报文来校验客户发送的证书，这个报文只能在具有签名作用的客户证书之后发送。
（4）结束。客户发送change_cipher_spec报文并将挂起的CipherSpec复制到当前的CipherSpec。这个报文使用的是改变密码格式协议。然后，客户在新的算法、对称密钥和MAC秘密之下立即发送finished报文。finished报文验证密钥交换和鉴别过程是成功的。服务器对这两个报文响应，发送自己的change_cipher_spec报文、finished报文。握手结束，客户与服务器可以发送应用层数据了。