SSL简介

注：本文基于互联网内容整合而成，非原创。参考文章参加【7.参考资料】。引用时请附上原文地址。

SSL（Secure Socket Layer，安全套接字层）是位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。
IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

1. 信息安全
如果说两个人之间的通信是安全的，那么如何定义这个安全呢？

- 保密性（Confidentiality）
保密性应该很容易理解，就是只有你自己和你允许的人能看到相关的信息。这和物理文件的保密性是一样的。

- 完整性（Integrity）
所谓完整性就是你的信息没有被破坏或者篡改过。举个例子比如网络聊天，保证对方收到的信息就是你发出的信息也是信息安全的一部分。

- 可获得性（Availability）
可获得性是指你自己在需要的时候能够访问到信息或者保证对方能够收到你的信息。

通常，我们平时说的“安全”往往只包括第一点，保密性。其实后面两点也是很重要的，特别是在信息安全领域。如果没有完整性和可获得性，光保密又有什么用呢？回到我们的主题，SSL和数字证书主要关注的是前两点。至于可获得性就需要涉及到硬件，管理等等了。

现在的问题是，我们如何保证上面所定义的“安全”？通常，有以下两个方法：

- 认证（Authentication）
认证是证明你就是那个你所声称的那个人。举个例子，你说你是张三，然后去机场登机，机场工作人员怎么知道你就是张三呢？你必须出示你的身份证或者护照，这样就可以证明你就是那个你所声称的张三。在信息安全领域也一样，比如你想去google查看zhlmmc的邮件，然后google会问你要zhlmmc的密码，因为只有zhlmmc知道zhlmmc帐户的密码，如果你能说出那个密码，那么你就是zhlmmc，google就会把zhlmmc的邮件返回给你。有些文章把这个过程称为Identification。

- 授权（Authorization）
授权是指一个系统里面有很多用户，有些用户能做某些事情，有些用户不能做某些事情。比如Linux，很多用户可以同时通过认证而登录到Linux主机，但是只有root才能修改或删除系统文件，普通用户只能修改自己的home。

这里每一点都可能涉及很多不同的技术来保证过程的顺利进行。“授权”跟业务逻辑的牵扯比较大，SSL和数字证书更多的关注第一点。

2. 加密解密

加密是保护信息安全的常用手段之一。对信息的加密是需要加密算法的，如果加密算法被破解了，那么一切免谈。不过，基本上，要破解一个加密算法是非常非常困难的。至少，目前流行的加密算法还是安全的，所以我们也就不必考虑这个问题了。

- 散列（Hash）

经常用bt下载的人应该很熟悉这个。这就是MD5啊~虽然Hash不只是MD5，常见的还有SHA1。不过MD5最流行所以一般大家说的hash就是它了。值得一提的是，山东大学的王小云在2005年的时候发了一篇“ How to Break MD5 and Other Hash Functions”引起了信息安全界的轰动。虽然我没仔细研读过这篇paper，不过我相信按照paper里面的说法要破解MD5还是很费劲的，要不早就出乱子了。所以我们就不考虑这个问题了。那么究竟什么是MD5呢？我来简单解释一下。

Hash就是一个工具，能把任意大小的文档变成一个 固定大小（MD5是32个字符）的字符串。并且，这个过程是不可逆的，也就是说，没有任何办法从那个字符串得到原来那个文档。还有很重要的一点是， 任意两个文档（哪怕极其相似）得到相同字符串的概率几乎等于0。现在你有一个10000字的文章，发给你的朋友，那你的朋友怎么判断他收到的文章一个标点符号都没有少呢？你在发送文章的同时把这个文章的Hash字符串也发过去，这样你的朋友收到文章以后，根据收到的文章重新计算一遍这个字符串，如果这个字符串和你发过去的一样，那就证明你朋友收到的文章是和你发送的一模一样。

- 对称加密（Symmetric Cryptography）

所谓加密就是把一段能看懂的东西通过某种变换变成看不懂的东西。当然这种变换是可逆的，否则加密有什么用啊！这里所说的“变换”就是加密算法。目前我们所说的加密算法基本上都是基于密钥的。加密算法不能单独工作，必须有密钥配合。就像现实生活中的锁，同一型号的锁的原理都一样，但是没把锁都有各自的钥匙，用来开锁和关锁。 加密的算法是公开的，但密钥是保密的。自己“发明”加密算法是很愚蠢的，除非你是密码学专家。历史上有很多使用自己发明的加密算法的笑话，往往你发明的算法都是自以为是，其实很容易破解的拉。而目前流行的加密算法都是经过时间和众人检验的，一般情况下，只要密钥不泄露，那就是安全的。有一点要说明的是，虽然我们平时一般说“加密算法”，但往往这个加密算法都包含解密算法的。 “对称加密”是指加密和解密的密钥是同一个。目前流行的对称加密算法有DES，AES，Blowfish等等。举个例子，你有一篇文章想要发给你朋友，但是你不想让别人看见这篇文章所以你选择AES加密。用的密钥是你和你朋友事先约定的，只有你们两个人知道。在发送之前，你用AES算法和约定好的密钥给文章加密，然后把加密过的文章发送给你的朋友。你朋友收到以后可以用AES算法和那个密钥解密而获得原始的那篇文章。 对称加密算法的优点是速度快，缺点是密钥管理不方便，要求共享密钥。

- 非对称加密（Asymmetric Cryptography）

如果你理解了上面讲的对称加密，那么这里的非对称加密就很简单了。从字面上理解就可以猜到， 加密和解密不是用的同一个密钥，其中一个称为公钥（public key），另一个称为私钥（private key）。公钥就是公开的，大家都知道，而私钥只有你自己知道。这两个密钥在数学上是有联系的，用公钥加密的内容只能由相应的私钥来解密，反过来，用私钥加密的内容只能由相应的公钥来解密。另外很重要的一点是， 不能从公钥推导出私钥，或者说很困难。常用的非对称加密算法有RSA，ECC等等。举个例子，你想要把一篇文章发送给你的朋友，但是不想让别人看到这篇文章。除了用上面讲的方法以外，你还可以用非对称加密来实现。在发送之前，你把文章用你朋友的公钥加密（公钥是公开的，每个人都知道），然后把加密过后的文章发送给你的朋友，你的朋友可以用他的私钥来解密。其他人获得了你传送的内容都是没有用的，因为只有你朋友有私钥可以解密。 非对称加密算法的优点是密钥管理很方便，缺点是速度慢。

3. 数字签名

我们先来看看现实生活中的签名是如何实现的。比如为信用卡账单签名，商家会打印一张消费单子给你，你看过以后觉得没有问题，于是在这张纸上签上自己的大名，表示你承认了这笔消费，并同意商家从你的信用卡账户扣钱。而商家可以对比你的签名和信用卡背后的签名是否一致来验证你是否冒用别人的信用卡（事实上很多商家不看的哦）。这个流程是基于一个假设的： 只有你自己能重现你的签名。虽然我们不能每次都签的一摸一样，但是通过笔迹鉴定，我们可以确定这个签名是否出自你手。分析一下，签名具有哪些特点呢？

- 不可伪造 - 通过笔记鉴定来保证。
- 不可移植，复制 - 复印，剪贴的签名当然无效咯！
- 不可否认 – 因为不可伪造，不可移植，不可复制，所以不可否认。

相似的，在虚拟世界里，我们有数字签名来帮助证明某个文档是你创建的，或者是你认可的。 数字签名所用的技术是散列和非对称加密。数字签名的假设是： 只有你自己有你的私钥。根据前面对散列的介绍，我们先为你要签名的信息生成一个Hash字串，Hash1，然后用你的私钥加密得到Encrypted(Hash1)，这就是你对这个文档的数字签名。当别人需要验证某个文档是否是你签名的时候，只需要用你的公钥解密你的签名得到Hash1，并和该文档计算出来的Hash2对比，查看是否一致。如果一致则说明你确实对该文档签过名，否则就是没有。下面来分析一下，数字签名是如何保证上面所讲的签名的特点的。

不可伪造：
　　因为只有你有你自己的私钥，所以任何其他人都无法产生用你的私钥加密过的Hash1。
不可移植，复制：
　　你对文档A的签名不可能对文档B也有效，因为你对文档B的签名必然和对A的签名不一样，这是由Hash的唯一性保证的。拿你对A的签名去验证B是不可能通过的。
不可否认：
　　因为不可伪造，不可移植，不可复制，所以不可否认。

仔细想想数字签名和现实生活中的签名真的蛮像的，逻辑上是一样的。或许你在想，为什么要对Hash加密呢？我直接对文档用我的私钥加密不就完了嘛？对啊，效果是一样的，但是效率不一样哦~别忘了非对称算法是很慢的，加密一个100M的文件要算半天呢！

这里要顺便提一下消息认证码（ Message Authentication Code）。 它和数字签名很相似，只不过它是用对称加密 的而数字签名用的是非对称加密。

在现实生活中，各种加密手段往往是配合使用以达到最好的效果和效率。SSL和数字证书就是混合了各种的加密手段。

4. 数字证书

前面提到的认证（Authentication）的时候说，现实生活中可以用身份证和护照来证明身份， 那么在虚拟世界里，数字证书就是身份证。和现实生活不同的是，并不是每个上网的用户都有数字证书的，往往只有当一个人需要证明自己的身份的时候才需要用到数字证书。那么什么时候需要证明自己的身份呢？普通用户一般是不需要的，网站并不关心是谁访问了网站，现在的网站只关心流量啊~反过来，网站就需要证明自己的身份了。比如你想要提交信用卡信息给预定航班的网站，那么你如何确定你正在访问的网站就是你所想要访问的那个呢？现在 钓鱼网站很多的。比如你想访问的是“www.ctrip.com”，但其实你访问的是“www.otrip.com”，所以在提交自己的信息之前你需要验证一下网站的身份，要求网站出示数字证书。一般正常的网站都会主动出示自己的数字证书。
理论上，人人都可以找个证书工具，自己做一个证书。那如何防止坏人自己制作证书出来骗人？
我们的身份证是由公安机关颁发的，并加有很多防伪技术，不能伪造（或者说很难）。同样的，数字证书也有专门的发证机关（Certificate Authority，简称CA，其实是一些商业公司）。

什么是CA？
　　CA是Certificate Authority的缩写，也叫“证书授权中心”。
　　它是负责管理和签发证书的第三方机构一般来说，CA必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任C公司，才会找 C 公司作为公章的中介。
什么是CA证书？
　　CA 证书，顾名思义，就是CA颁发的证书。
　　前面已经说了，人人都可以找工具制作证书。但是你不是权威的CA机关，你自己制作的证书不具有权威性。
　　这就好比某个坏人自己刻了一个公章，盖到介绍信上。但是别人一看，不是受信任的中介公司的公章，就不予理睬，坏蛋的阴谋就不能得逞。
什么是证书之间的信任关系？
　　证书间的信任关系，就是用一个证书来证明另一个证书是真实可信的。
什么是证书信任链？
　　实际上，证书之间的信任关系，是可以嵌套的。比如，C 信任 A1，A1 信任 A2，A2 信任 A3......这个叫做证书的信任链。只要你信任链上的头一个证书，那后续的证书，都是可以信任滴。
什么是根证书？
　　“根证书”的英文是“root certificate”。除了根证书，其它证书都要依靠上一级的证书，来证明自己。那谁来证明“根证书”可靠？实际上，根证书自己证明自己是可靠滴（或者换句话说，根证书是不需要被证明）。
根证书是整个证书体系安全的根本。所以，如果某个证书体系中，根证书出了问题（不再可信了），那么所有被根证书所信任的其它证书，也就不再可信了。

比较常见的发证机关是VeriSign。数字证书的发证机关会对自己发放的证书加上自己的数字签名，以保证证书不能被伪造。那数字证书到底包含了些什么呢？

- 持有者姓名（Common Name）
- 发证机关（Issuer）
- 有效日期（Validity）
- 证书持有人的公钥（Subject’s Public Key Info）
- 扩展信息 （Extension）
- 用发证机关对该证书的数字签名（Certificate Signature）

5. SSL/TLS的基本原理
SSL协议提供的服务主要有：
1）认证用户和服务器，确保数据发送到正确的客户机和服务器；
2）加密数据以防止数据中途被窃取；
3）维护数据的完整性，确保数据在传输过程中不被改变。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

（1）如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
（2）公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成"对话密钥"。
（3） 双方采用"对话密钥"进行加密通信。
上面过程的前两步，又称为"握手阶段"（handshake）。

"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。

5.1 客户端发出请求（ClientHello）
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息。
（1） 支持的协议版本，比如TLS 1.0版。
（2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。
（3） 支持的加密方法，比如RSA公钥加密。
（4） 支持的压缩方法。
这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

5.2 服务器回应（SeverHello）
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。
（3） 确认使用的加密方法，比如RSA公钥加密。
（4） 服务器证书。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

5.3 客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
至于为什么一定要用三个随机数，来生成"会话密钥"，dog250解释得很好：
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

5.4 服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，用"会话密钥"加密内容。

也许，你在想，“现在还不简单吗？用这个对称密钥加密传输数据呗！”。否，没那么简单。先来看一下结果，等会儿再解释原因。在通信双方协商出一个对称密钥以后，他们用这个密钥来加密传输的数据。同时为每个消息生成时间戳，用此密钥为消息和相应的时间戳生成消息认证码（MAC）。也就是说，每次发送的内容包括 Encrypt(message) + MAC(message + timestamp)
这么做有几个好处：

1）防止消息的篡改

所谓消息篡改就是有第三者插在通信双方之间，篡改往来的消息。由于消息是加密的，第三者不能获得消息的内容，但是他可以闭着眼睛瞎改。如果没有MAC的话，接受者就无法判断此消息是否被篡改过。

2）防止消息重放

消息的重放是只第三者记录下通信双方的每一次发送的消息，虽然他不能获得消息的内容。但是它可以通过重新发送客户端或者服务端的信息来把自己装成是客户端或者服务端。如果在MAC里面加上了时间戳，消息接收方验证时间戳就可以阻止消息的重放攻击。

通过上面对SSL的分析，我们可以看到，SSL并不能阻止别人获得你传输的数据，但是由于你传输的数据都是加密过的，别人拿到了毫无用处，一样可以保护信息的安全。还有一点需要强调一下，SSL并不依赖于TCP，它可以建立在任何可靠的传输层协议（比如TCP）之上。也就是说SSL是不能建立在UDP之上的。这是显然的，如果传输都不可靠，偶尔丢两个包或者包的顺序换一换的话，怎么保证安全呢？

6. 使用OPENSSL建立CA和签发证书
建立 CA
建立 CA 目录结构
按照 OpenSSL 的默认配置建立 CA ，需要在文件系统中建立相应的目录结构。相关的配置内容一般位于 /usr/ssl/openssl.cnf 内，详情可参见 config (1) 。在终端中使用如下命令建立目录结构：

$ mkdir -p ./demoCA/{private,newcerts}
$ touch ./demoCA/index.txt
$ echo 01 > ./demoCA/serial

产生的目录结构如下：

.
`-- demoCA/
|-- index.txt
|-- newcerts/
|-- private/
`-- serial

生成 CA 证书的 RSA 密钥对
首先，我们要为 CA 建立 RSA 密钥对。打开终端，使用如下命令生成 RSA 密钥对：

$ openssl genrsa -des3 -out ./demoCA/private/cakey.pem 2048

参数解释
genrsa

用于生成 RSA 密钥对的 OpenSSL 命令。

-des3

使用 3-DES 对称加密算法加密密钥对，该参数需要用户在密钥生成过程中输入一个口令用于加密。今后使用该密钥对时，需要输入相应的口令。如果不加该选项，则不对密钥进行加密。

-out ./demoCA/private/cakey.pem

令生成的密钥对保存到文件 ./demoCA/private/cakey.pem 。

2048

RSA 模数位数，在一定程度上表征了密钥强度。

该命令输出如下，用户应输入自己的密钥口令并确认：

Generating RSA private key, 2048 bit long modulus
................................................+++
.........................+++
e is 65537 (0x10001)
Enter pass phrase for ./demoCA/private/cakey.pem:<enter your pass-phrase>
Verifying - Enter pass phrase for ./demoCA/private/cakey.pem:<re-enter your pass-phrase>
生成 CA 证书请求
为了获取一个 CA 根证书，我们需要先制作一份证书请求。先前生成的 CA 密钥对被用于对证书请求签名。

$ openssl req -new -days 365 -key ./demoCA/private/cakey.pem -out careq.pem

参数解释
req

用于生成证书请求的 OpenSSL 命令。

-new

生成一个新的证书请求。该参数将令 OpenSSL 在证书请求生成过程中要求用户填写一些相应的字段。

-days 365

从生成之时算起，证书时效为 365 天。

-key ./demoCA/private/cakey.pem

指定 ./demoCA/private/cakey.pem 为证书所使用的密钥对文件。

-out careq.pem

令生成的证书请求保存到文件 careq.pem 。

该命令将提示用户输入密钥口令并填写证书相关信息字段，输出如下：

Enter pass phrase for ./demoCA/private/cakey.pem:<enter you pass-phrase>
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:ZJ
Locality Name (eg, city) []:HZ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Some Ltd. Corp.
Organizational Unit Name (eg, section) []:Some Unit
Common Name (eg, YOUR name) []:Someone
Email Address []:some@email.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

对 CA 证书请求进行签名
在实际应用中，用户可以通过向知名 CA 递交证书请求来申请证书。但是在这里，我们需要建立的是一个根 CA ，只能由我们自己来对证书请求进行签名。所以我们让 OpenSSL 使用证书请求中附带的密钥对对该请求进行签名，也就是所谓的“ self sign ”：

$ openssl ca -selfsign -in careq.pem -out cacert.pem

参数解释
ca

用于执行 CA 相关操作的 OpenSSL 命令。

-selfsign

使用对证书请求进行签名的密钥对来签发证书。

-in careq.pem

指定 careq.pem 为证书请求文件。

-out ./demoCA/cacert.pem

指定 ./demoCA/cacert.pem 为输出的证书。

该命令要求用户输入密钥口令并输出相关证书信息，请求用户确认：

Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:<enter your pass-phrase>
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Jan 16 13:05:09 2008 GMT
Not After : Jan 15 13:05:09 2009 GMT
Subject:
countryName = CN
stateOrProvinceName = ZJ
organizationName = Some Ltd. Corp.
organizationalUnitName = Some Unit
commonName = Someone
emailAddress = some@email.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
75:F5:3C:CC:C1:5E:6D:C3:8B:46:A8:08:E6:EA:29:E8:22:7E:70:03
X509v3 Authority Key Identifier:
keyid:75:F5:3C:CC:C1:5E:6D:C3:8B:46:A8:08:E6:EA:29:E8:22:7E:70:03

Certificate is to be certified until Jan 15 13:05:09 2009 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

一步完成 CA 证书请求生成及签名
以上两个步骤可以合二为一。利用 ca 命令的 -x509 参数，通过以下命令同时完成证书请求生成和签名从而生成 CA 根证书：

$ openssl req -new -x509 -days 365 -key ./demoCA/private/cakey.pem -out ./demoCA/cacert.pem

参数解释
req

用于生成证书请求的 OpenSSL 命令。

-new

生成一个新的证书请求。该参数将令 OpenSSL 在证书请求生成过程中要求用户填写一些相应的字段。

-x509

生成一份 X.509 证书。

-days 365

从生成之时算起，证书时效为 365 天。

-key ./demoCA/private/cakey.pem

指定 cakey.pem 为证书所使用的密钥对文件。

-out ./demoCA/cacert.pem

令生成的证书保存到文件 ./demoCA/cacert.pem 。

该命令输出如下，用户应输入相应的字段：

Enter pass phrase for ./demoCA/private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:ZJ
Locality Name (eg, city) []:HZ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Some Ltd. Corp.
Organizational Unit Name (eg, section) []:Some Unit
Common Name (eg, YOUR name) []:Someone
Email Address []:some@email.com

至此，我们便已成功建立了一个私有根 CA 。在这个过程中，我们获得了一份 CA 密钥对文件 ./demoCA/private/cakey.pem 以及一份由此密钥对签名的 CA 根证书文件 ./demoCA/cacert.pem ，得到的 CA 目录结构如下：

.
|-- careq.pem
`-- demoCA/
|-- cacert.pem
|-- index.txt
|-- index.txt.attr
|-- index.txt.old
|-- newcerts/
| `-- 01.pem
|-- private/
| `-- cakey.pem
|-- serial
`-- serial.old

注：如果在 CA 建立过程中跳过证书请求生成的步骤，则不会产生 careq.pem 文件。

签发证书
下面我们就可以利用建立起来的 CA 进行证书签发了。

生成用户证书 RSA 密钥对
参照 CA 的 RSA 密钥对生成过程，使用如下命令生成新的密钥对：

$ openssl genrsa -des3 -out userkey.pem
Generating RSA private key, 512 bit long modulus
....++++++++++++
...++++++++++++
e is 65537 (0x10001)
Enter pass phrase for userkey.pem:<enter your pass-phrase>
Verifying - Enter pass phrase for userkey.pem:<re-enter your pass-phrase>

生成用户证书请求
参照 CA 的证书请求生成过程，使用如下命令生成新的证书请求：

$ openssl req -new -days 365 -key userkey.pem -out userreq.pem
Enter pass phrase for userkey.pem:<enter your pass-phrase>
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:ZJ
Locality Name (eg, city) []:HZ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Some Ltd. Corp.
Organizational Unit Name (eg, section) []:Some Other Unit
Common Name (eg, YOUR name) []:Another
Email Address []:another@email.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

签发用户证书
现在，我们可以用先前建立的 CA 来对用户的证书请求进行签名来为用户签发证书了。使用如下命令：

$ openssl ca -in userreq.pem -out usercert.pem

参数解释
ca

用于执行 CA 相关操作的 OpenSSL 命令。

-in userreq.pem

指定用户证书请求文件为 userreq.pem 。

-out usercert.pem

指定输出的用户证书文件为 usercert.pem 。

该命令要求用户输入密钥口令并输出相关证书信息，请求用户确认：

Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:<enter your pass-phrase>
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Jan 16 14:50:22 2008 GMT
Not After : Jan 15 14:50:22 2009 GMT
Subject:
countryName = CN
stateOrProvinceName = ZJ
organizationName = Some Ltd. Corp.
organizationalUnitName = Some Other Unit
commonName = Another
emailAddress = another@email.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
&nb sp; X509v3 Subject Key Identifier:
97:E7:8E:84:B1:45:27:83:94:A0:DC:24:79:7B:83:97:99:0B:36:A9
X509v3 Authority Key Identifier:
keyid:D9:87:12:94:B2:20:C7:22:AB:D4:D5:DF:33:DB:84:F3:B0:4A:EC:A2

Certificate is to be certified until Jan 15 14:50:22 2009 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

至此，我们便完成了 CA 的建立及用户证书签发的全部工作。不妨把所有 shell 命令放到一起纵览一下：

# 建立 CA 目录结构
mkdir -p ./demoCA/{private,newcerts}
touch ./demoCA/index.txt
echo 01 > ./demoCA/serial

# 生成 CA 的 RSA 密钥对
openssl genrsa -des3 -out ./demoCA/private/cakey.pem 2048

# 生成 CA 证书请求
openssl req -new -days 365 -key ./demoCA/private/cakey.pem -out careq.pem

# 自签发 CA 证书
openssl ca -selfsign -in careq.pem -out ./demoCA/cacert.pem

# 以上两步可以合二为一
openssl req -new -x509 -days 365 -key ./demoCA/private/cakey.pem -out ./demoCA/cacert.pem

# 生成用户的 RSA 密钥对
openssl genrsa -des3 -out userkey.pem

# 生成用户证书请求
openssl req -new -days 365 -key userkey.pem -out userreq.pem

# 使用 CA 签发用户证书
openssl ca -in userreq.pem -out usercert.pem

了解了这些基础步骤之后，就可以通过脚本甚至 makefile 的方式来将这些工作自动化。 CA.pl 和 CA.sh 便是对 OpenSSL 的 CA 相关功能的简单封装，在 Debian 系统中，安装了 OpenSSL 后，可以在 /usr/lib/ssl/misc/ 目录下找到这两个文件。

7. 参考资料
SSL与TLS的区别以及介绍：http://kb.cnblogs.com/page/197396/
SSL与数字证书的基本概念和工作原理：http://www.linuxde.net/2012/03/8301.html
数字证书及CA的扫盲介绍：http://kb.cnblogs.com/page/194742/
SSL/TLS协议运行机制的概述：http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
SSL协议详解： http://kb.cnblogs.com/page/162080/
基于OpenSSL的CA 建立及证书签发：http://www.cnblogs.com/dvking/archive/2010/01/09/2368719.html