本文非原创，图片等资源都来自原博，仅供学习之用。原博见脚注。
基于万维网的电子商务和网上银行等新兴应用，极大地方便了人们的日常生活。受到人们的青睐。
因为这些应用都须要在网络上进行在线交易，它们对网络通信的安全性提出了更高的要求。传统的万维网协议HTTP不具备安全机制——采用明文的形式数据传输、不能验证通信两方的身份、无法防止传输的数据被篡改等，导致HTTP无法满足电子商务和网上银行等应用的安全性要求。
Netscape公司提出的安全协议SSL，利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。SSL能够为HTTP提供安全连接，从而非常大程度上改善了万维网的安全性问题。
SSL具有例如以下长处：
提供较高的安全性保证。 SSL利用数据加密、身份验证和消息完整性验证机制。保证网络上传输数据的安全性。
支持各种应用层协议。 尽管SSL设计的初衷是为了解决万维网安全性问题，可是因为SSL位于应用层和传输层之间。它能够为不论什么基于TCP等可靠连接的应用层协议提供安全性保证。
部署简单。 眼下SSL已经成为网络中用来鉴别站点和网页浏览者身份，在浏览器使用者及Webserver之间进行加密通信的全球化标准。SSL协议已被集成到大部分的浏览器中，如IE、Netscape、Firefox等。这就意味着差点儿随意一台装有浏览器的计算机都支持SSL连接。不须要安装额外的client软件。
SSL协议实现的安全机制包含：
传输数据的机密性：利用对称密钥算法对传输的数据进行加密。
身份验证机制：基于证书利用数字签名方法对server和client进行身份验证，当中client的身份验证是可选的。
消息完整性验证：消息传输过程中使用MAC算法来检验消息的完整性。
网络上传输的数据非常容易被非法用户窃取，SSL采用在通信两方之间建立加密通道的方法保证传输数据的机密性。
所谓加密通道，是指发送方在发送数据前，使用加密算法和加密密钥对数据进行加密，然后将数据发送给对方。接收方接收到数据后，利用解密算法和解密密钥从密文中获取明文。没有解密密钥的第三方，无法将密文恢复为明文，从而保证传输数据的机密性。
加解密算法分为两类：
对称密钥算法：数据加密和解密时使用同样的密钥。
非对称密钥算法：数据加密和解密时使用不同的密钥，一个是公开的公钥，一个是由用户秘密保存的私钥。
利用公钥（或私钥）加密的数据仅仅能用对应的私钥（或公钥）才干解密。
与非对称密钥算法相比。对称密钥算法具有计算速度快的长处，通经常使用于对大量信息进行加密（如对全部报文加密）；而非对称密钥算法，一般用于数字签名和对较少的信息进行加密。
SSL加密通道上的数据加解密使用对称密钥算法。眼下主要支持的算法有DES、3DES、AES等，这些算法都能够有效地防止交互数据被窃听。
对称密钥算法要求解密密钥和加密密钥全然一致。因此，利用对称密钥算法加密数据传输之前。须要在通信两端部署同样的密钥。
电子商务和网上银行等应用中必须保证要登录的Webserver是真实的，以免重要信息被非法窃取。SSL利用数字签名来验证通信对端的身份。
非对称密钥算法能够用来实现数字签名。因为通过私钥加密后的数据仅仅能利用相应的公钥进行解密，因此依据解密是否成功，就能够推断发送者的身份。如同发送者对数据进行了“签名”。比如。Alice使用自己的私钥对一段固定的信息加密后发给Bob，Bob利用Alice的公钥解密，假设解密结果与固定信息同样。那么就能够确认信息的发送者为Alice，这个过程就称为数字签名。
SSLclient必须验证SSLserver的身份，SSLserver是否验证SSLclient的身份。则由SSLserver决定。SSLclient和SSLserver的身份验证过程。请参见“3.2 SSL握手过程”。
使用数字签名验证身份时。须要确保被验证者的公钥是真实的，否则。非法用户可能会冒充被验证者与验证者通信。如图1所看到的。Cindy冒充Bob，将自己的公钥发给Alice，并利用自己的私钥计算出签名发送给Alice，Alice利用“Bob”的公钥（实际上为Cindy的公钥）成功验证该签名，则Alice觉得Bob的身份验证成功，而实际上与Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的机制保证公钥的真实性，具体介绍请参见“2.5 利用PKI保证公钥的真实性”。
为了避免网络中传输的数据被非法篡改，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。
MAC算法是在密钥参与下的数据摘要算法，能将密钥和随意长度的数据转换为固定长度的数据。利用MAC算法验证消息完整性的过程如图2所看到的。
发送者在密钥的参与下，利用MAC算法计算出消息的MAC值。并将其加在消息之后发送给接收者。接收者利用相同的密钥和MAC算法计算出消息的MAC值。并与接收到的MAC值比较。假设二者相同。则报文没有改变；否则，报文在传输过程中被改动，接收者将丢弃该报文。
MAC算法具有例如以下特征，使其可以用来验证消息的完整性：
消息的不论什么改变，都会引起输出的固定长度数据产生变化。通过比较MAC值，可以保证接收者可以发现消息的改变。
MAC算法须要密钥的参与。因此没有密钥的非法用户在改变消息的内容后，无法加入正确的MAC值。从而保证非法用户无法任意改动消息内容。
对称密钥算法和MAC算法要求通信两方具有同样的密钥。否则解密或MAC值验证将失败。因此。要建立加密通道或验证消息完整性，必须先在通信两方部署一致的密钥。
SSL利用非对称密钥算法加密密钥的方法实现密钥交换，保证第三方无法获取该密钥。如图3所看到的，SSLclient（如Web浏览器）利用SSLserver（如Webserver）的公钥加密密钥，将加密后的密钥发送给SSLserver。仅仅有拥有相应私钥的SSLserver才从密文中获取原始的密钥。SSL通常采用RSA算法加密传输密钥。
实际上，SSLclient发送给SSLserver的密钥不能直接用来加密数据或计算MAC值。该密钥是用来计算对称密钥和MAC密钥的信息，称为premaster secret。SSLclient和SSLserver利用premaster secret计算出同样的主密钥（master secret）。再利用master secret生成用于对称密钥算法、MAC算法等的密钥。premaster secret是计算对称密钥、MAC算法密钥的关键。
用来实现密钥交换的算法称为密钥交换算法。非对称密钥算法RSA用于密钥交换时，也能够称之为密钥交换算法。
利用非对称密钥算法加密密钥之前，发送者须要获取接收者的公钥，并保证该公钥确实属于接收者。否则。密钥可能会被非法用户窃取。如图1所看到的。Cindy冒充Bob，将自己的公钥发给Alice。Alice利用Cindy的公钥加密发送给Bob的数据。Bob因为没有相应的私钥无法解密该数据，而Cindy截取数据后，能够利用自己的私钥解密该数据。SSL利用PKI提供的机制保证公钥的真实性，具体介绍请参见“2.5 利用PKI保证公钥的真实性”。
PKI通过数字证书来公布用户的公钥，并提供了验证公钥真实性的机制。数字证书（简称证书）是一个包括用户的公钥及其身份信息的文件，证明了用户与公钥的关联。
数字证书由权威机构——CA签发，并由CA保证数字证书的真实性。
SSLclient把密钥加密传递给SSLserver之前，SSLserver须要将从CA获取的证书发送给SSLclient，SSLclient通过PKI推断该证书的真实性。假设该证书确实属于SSLserver，则利用该证书中的公钥加密密钥，发送给SSLserver。
验证SSLserver/SSLclient的身份之前，SSLserver/SSLclient须要将从CA获取的证书发送给对端。对端通过PKI推断该证书的真实性。
假设该证书确实属于SSLserver/SSLclient，则对端利用该证书中的公钥验证SSLserver/SSLclient的身份。
如图4所看到的，SSL位于应用层和传输层之间，它能够为不论什么基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层：
上层为SSL握手协议（SSL handshake protocol）、SSLpassword变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）。
底层为SSL记录协议（SSL record protocol）。
当中：
SSL握手协议：是SSL协议很重要的组成部分。用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在server和client之间安全地交换密钥、实现server和client的身份验证。
SSLpassword变化协议：client和server端通过password变化协议通知对端。随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
SSL警告协议：用来向通信对端报告告警信息，消息中包括告警的严重级别和描写叙述。
SSL记录协议：主要负责对上层的数据（SSL握手协议、SSLpassword变化协议、SSL警告协议和应用层协议报文）进行分块、计算并加入MAC值、加密。并把处理后的记录块传输给对端。
SSL通过握手过程在client和server之间协商会话参数，并建立会话。会话包括的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。
不同情况下，SSL握手过程存在差异。
以下将分别描写叙述以下三种情况下的握手过程：
仅仅验证server的SSL握手过程
验证server和client的SSL握手过程
恢复原有会话的SSL握手过程
如图5所看到的，仅仅须要验证SSLserver身份，不须要验证SSLclient身份时，SSL的握手过程为：
简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个ClientHello来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个ServerHello，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。
(1) SSLclient通过Client Hello消息将它支持的SSL版本号、加密算法、密钥交换算法、MAC算法等信息发送给SSLserver。
(2) SSLserver确定本次通信采用的SSL版本号和加密套件，并通过Server Hello消息通知给SSLclient。假设SSLserver同意SSLclient在以后的通信中重用本次会话，则SSLserver会为本次会话分配会话ID。并通过Server Hello消息发送给SSLclient。
(3) SSLserver将携带自己公钥信息的数字证书通过Certificate消息发送给SSLclient。
(4) SSLserver发送Server Hello Done消息。通知SSLclient版本号和加密套件协商结束。开始进行密钥交换。
(5) SSLclient验证SSLserver的证书合法后，利用证书中的公钥加密SSLclient随机生成的premaster secret，并通过Client Key Exchange消息发送给SSLserver。
(6) SSLclient发送Change Cipher Spec消息，通知SSLserver兴许报文将采用协商好的密钥和加密套件进行加密和MAC计算。
(7) SSLclient计算已交互的握手消息（除Change Cipher Spec消息外全部已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLserver。SSLserver利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，假设二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
(8) 相同地。SSLserver发送Change Cipher Spec消息，通知SSLclient兴许报文将采用协商好的密钥和加密套件进行加密和MAC计算。
(9) SSLserver计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLclient。SSLclient利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，假设二者相同。且MAC值验证成功。则证明密钥和加密套件协商成功。
SSLclient接收到SSLserver发送的Finished消息后。假设解密成功，则能够推断SSLserver是数字证书的拥有者，即SSLserver身份验证成功，由于仅仅有拥有私钥的SSLserver从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSLclient对SSLserver的身份验证。
说明： * Change Cipher Spec消息属于SSLpassword变化协议，其它握手过程交互的消息均属于SSL握手协议，统称为SSL握手消息。 * 计算Hash值。指的是利用Hash算法（MD5或SHA）将随意长度的数据转换为固定长度的数据。
SSLclient的身份验证是可选的，由SSLserver决定是否验证SSLclient的身份。
如图6中蓝色部分标识的内容所看到的，假设SSLserver验证SSLclient身份。则SSLserver和SSLclient除了交互“3.2.1 仅仅验证server的SSL握手过程”中的消息协商密钥和加密套件外，还须要进行下面操作：
(1) SSLserver发送Certificate Request消息。请求SSLclient将其证书发送给SSLserver。
(2) SSLclient通过Certificate消息将携带自己公钥的证书发送给SSLserver。SSLserver验证该证书的合法性。
(3) SSLclient计算已交互的握手消息、主密钥的Hash值。利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSLserver。
(4) SSLserver计算已交互的握手消息、主密钥的Hash值。利用SSLclient证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比较。假设二者同样，则SSLclient身份验证成功。
协商会话参数、建立会话的过程中。须要使用非对称密钥算法来加密密钥、验证通信对端的身份。计算量较大，占用了大量的系统资源。
为了简化SSL握手过程。SSL同意重用已经协商过的会话，详细过程为：
(1) SSLclient发送Client Hello消息，消息中的会话ID设置为计划重用的会话的ID。
(2) SSLserver假设同意重用该会话，则通过在Server Hello消息中设置同样的会话ID来应答。这样，SSLclient和SSLserver就能够利用原有会话的密钥和加密套件。不必又一次协商。
(3) SSLclient发送Change Cipher Spec消息，通知SSLserver报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
(4) SSLclient计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSLserver，以便SSLserver推断密钥和加密套件是否正确。
(5) 相同地。SSLserver发送Change Cipher Spec消息，通知SSLclient报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
(6) SSLserver计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSLclient。以便SSLclient推断密钥和加密套件是否正确。
HTTPS是基于SSL安全连接的HTTP协议。HTTPS通过SSL提供的数据加密、身份验证和消息完整性验证等安全机制。为Web访问提供了安全性保证，广泛应用于网上银行、电子商务等领域。
图8为HTTPS在网上银行中的应用。某银行为了方便客户，提供了网上银行业务，客户能够通过访问银行的Webserver进行帐户查询、转帐等。
通过在客户和银行的Webserver之间建立SSL连接，能够保证客户的信息不被非法窃取。
SSL VPN是以SSL为基础的VPN技术。利用SSL提供的安全机制，为用户远程访问公司内部网络提供了安全保证。如图9所看到的。SSL VPN通过在远程接入用户和SSL VPN网关之间建立SSL安全连接，同意用户通过各种Web浏览器，各种网络接入方式，在不论什么地方远程访问企业网络资源。并可以保证企业网络的安全，保护企业内部信息不被窃取。
[1] SSL工作原理 https://www.cnblogs.com/bhlsheji/p/4586597.html [2] SSL协商及密钥交换 https://blog.csdn.net/substitute_coder/article/details/57512131
读到这篇博客，对https的原理介绍的比较详细且生动，为了防止丢失，mark一下，以下是原文链接https://blog.51cto.com/11883699/2160032
众所周知，WEB服务存在http和https两种通信方式，http默认采用80作为通讯端口，对于传输采用不加密的方式，https默认采用443，对于传输的数据进行加密传输
目前主流的网站基本上开始默认采用HTTPS作为通信方式，一切的考虑都基于对安全的要求，那么如何对自己的网站配置HTTPS通信，是本文着重介绍的
本文的主要内容包括：https加密传输的原理、如何申请https所用的CA证书，如何配置WEB服务支持https
1、https原理通俗讲解
https=http+ssl，顾名思义，https是在http的基础上加上了SSL保护壳，信息的加密过程就是在SSL中完成的
首先我们先不谈https，先从一个简单的通讯原理图讲起：
http通信原理
客户端发送一句client hello给服务器端，服务器端返回一句serverhello给客户端，鉴于本文讨论是https的加密主题，我们只讨论信息传输的加密问题
实现客户端和服务端发送的信息client hello 和server hello，即使中间的包被窃取了，也无法解密传输的内容
http：client hello和server hello在通讯的过程中，以明文的形式进行传输，采用wireshark抓包的效果如下图：
有没有感觉这个的信息传输是完全暴露在互联网上面，你请求的所有信息都可以被窥测到，是不是感觉心一凉，不过不用担心，我们的安全信息现在都是采用https的传输，后面讲到https的时候大家心里会顿时轻松。但这不是最关键的，http的传输最大的隐患是信息劫持和篡改，如下图：
可以看到，http的信息传输中，信息很容易被×××给劫持，更有甚者，×××可以伪装服务器将篡改后的信息返回给用户，试想一下，如果×××劫持的是你的银行信息，是不是很可怕。所以对于http传出存在的问题可以总结如下：
（1）信息篡改：修改通信的内容
（2）信息劫持：拦截到信息通信的内容
这些是http不安全的体现，说完http，我们回到本文的主题https，看下人家是怎么保护信息的，所有的请求信息都采用了TLS加密，如果没有秘钥是无法解析传输的是什么信息
对于加密传输存在对称加密和非对称加密
对称加密 ——对称加密传输
当客户端发送Hello字符串的时候，在进行信息传输前，采用加密算法（上图中的秘钥S）将hello加密程JDuEW8&*21!@#进行传输，即使中间被×××劫持了，如果没有对应的秘钥S也无法知道传出的信息为何物，在上图中信息的加密和解密都是通过同一个秘钥进行的，对于这种加密我们称之为对称加密，只要A和B之间知道加解密的秘钥，任何第三方都无法获取秘钥S，则在一定条件下，基本上解决了信息通信的安全问题。但在现实的情况下（www），实际的通讯模型远比上图复杂，下图为实际的通信模型
server和所有的client都采用同一个秘钥S进行加解密，但大家思考下，如果这样的话，无异于没有加密，请做下思考
由于server和所有的client都采用同一个秘钥S，则×××们作为一个client也可以获取到秘钥S，此地无银三百两。所以在实际的通讯中，一般不会采用同一个秘钥，而是采用不同的秘钥加解密，如下图——通过协商的方式获取不同的秘钥
如上图，A和server通信采用对称加密A算法，B和server通信采用对称秘钥B算法，因此可以很好的解决了不同的客户端采用相同的秘钥进行通讯的问题
那现在又存在问题了，A通过明文传输和server协商采用了加密算法A，但这条信息本身是没有加密的，因此×××们还是可以窃取到秘钥的，整个的通讯仍然存在风险。那该如何处理呢？有人说，把这条信息（协调秘钥的过程）再次加密，那是不是还要协商加密秘钥，如此反复，永无止境。从根本上无法解决信息通讯的安全问题
如何对协商过程进行加密 （ 非对称加密原理图）
在密码学跟对称加密一起出现的，应用最广的加密机制“非对称加密”，如上图，特点是私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。
基于上述的特点，我们可以得出如下结论：
（1）公钥是开放给所有人的，但私钥是需要保密的，存在于服务端
（2）服务器端server向client端（A、B…）的信息传输是不安全的：因为所有人都可以获取公钥
（3）但client端（A、B…）向server端的信息传输确实安全的：因为私钥只有server端存在
因此，如何协商加密算法的问题，我们解决了，非对称加密算法进行对称加密算法协商过程。
在这里我们做个小结： 信息通信采用http是不安全的，存在信息劫持、篡改的风险，https是加密传输，是安全的通信，对于https加密的过程，我们首先介绍的对称加密，采用对称加密进行通信存在秘钥协商过程的不安全性，因此我们采用了非对称加密算法解决了对协商过程的加密，因此https是集对称加密和非对称加密为一体的加密过程
安全的获取公钥
细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。
这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？
client获取公钥最最直接的方法是服务器端server将公钥发送给每一个client用户，但这个时候就出现了公钥被劫持的问题，如上图，client请求公钥，在请求返回的过程中被×××劫持，那么我们将采用劫持后的假秘钥进行通信，则后续的通讯过程都是采用假秘钥进行，数据库的风险仍然存在。在获取公钥的过程中，我们又引出了一个新的话题：如何安全的获取公钥，并确保公钥的获取是安全的， 那就需要用到终极武器了：SSL 证书（需要购买）和CA机构
如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性
以浏览器为例说明如下整个的校验过程：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
至此第一部分关于HTTPS的原理介绍已经结束了，总结一下：
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
openssl version -a查看ssl是否安装和安装路径
首先，了解一下证书的类型。
SSL证书包括：
1，CA证书，也叫根证书或者中间级证书。如果是单向https认证的话，该证书是可选的。不安装CA证书的话，浏览器默认是不安全的。CA 认证分为三类：DV ( domain validation)，OV ( organization validation)，EV ( extended validation)，证书申请难度从前往后递增，貌似 EV 这种不仅仅是有钱就可以申请的。对于一般的小型网站尤其是博客，或者在内网的测试环境中，为了验证https的一些问题，我们可以自建Root CA ，使用自签名证书来构建安全网络，所谓自签名证书，就是自己扮演 CA 机构，自己给自己的服务器颁发免费的证书。
（注：这里的证书我们用OpenSSL就可以生成，但是只有经过认证的CA机构签发的根证书才会被浏览器或其它设备信任，做法就是预先在浏览器或系统里内置可信的根证书。）
2，服务器证书，必选项。通过key，证书请求文件csr，再通过CA证书签名，生成服务器证书。
3，客户端证书，可选项。若有客户端证书则是双向https验证。
以上所有证书都可以自己生成。
了解linux中，约定俗成的证书文件后缀
linux系统是不以后缀名来判断文件类型的，但是为了我们能够更好地判断文件用途，所以添加各种后缀。以下是约定成俗的后缀。
*.key：密钥文件，一般是SSL中的私钥，通常是rsa算法，分带口令和不带口令的版本；
*.csr：证书请求文件，里面包含公钥和其他信息，通过签名后就可以生成证书；用于向证书颁发机构申请crt证书时使用，服务器配置时不会用到；在制作csr文件的时，必须使用自己的私钥来签署申，还可以设定一个密钥.
*.crt, *.cert：CA认证后的证书文件，包含公钥，签名和其他需要认证的信息，比如主机名称（IP）等。
*.pem：里面一般包含私钥和证书的信息。
我们自签名证书配置，虚拟主机需要的是.crt证书，和不带口令的SSL Key的.key文件。
linux下openssl生成 签名的步骤：
公钥和私钥通常是成对出现的，有了公钥那就存在对应的私钥，通常OpenSSL，公钥是很容易从私钥中得到的，因而我们要创建证书，那我们首先要做的就是创建私钥。
key的生成 （生成服务器私钥）
openssl genrsa -des3 -out server.key 2048
这样是生成rsa私钥，des3算法，openssl格式，2048位强度。server.key是密钥文件名。为了生成这样的密钥，需要一个至少四位的密码。
可以通过以下方法生成没有密码的key:
openssl rsa -in server.key -out server.key
server.key就是没有密码的版本了。
-genrsa：指定了生成了算法使用RSA
-desc：表示生成的key是有密码保护的（注：如果是将生成的key与server的证书一起使用，最好不需要密码，就是不要这个参数，否则其它人就会在请求的时候每次都要求输入密码）
-out：后面的参数表示生成的key的输入文件
2048：表示的是生成key的大小，单为字节(bits)，看证书提供商要求，比如Godaddy规定是2048
-in : 指定要加密的文件存放路径
2. 生成CA的crt
openssl req -new -x509 -key server.key -out ca.crt -days 3650
生成的ca.crt文件是用来签署下面的server.csr文件。
req: 配置参数-x509指定使用 X.509证书签名请求管理(certificate signing request (CSR))."X.509" 是一个公钥代表that SSL and TLS adheres to for its key and certificate management.
-rep: 指定要加密的文件存放路径
-new: 表示生成一个新证书部署请求
-x509: 专用于CA生成自签证书，如果不是自签证书则不需要此项
-key: 生成请求时用到的私钥文件
-day: 证书的有效期，单位是天，默认是365天
3. 使用第1点的key去 生成csr（certificate signing request）
openssl req -new -key server.key -out server.csr
需要依次输入国家，地区，组织，email。最重要的点有两个，一个是域名，一定要是你的域名后缀，并且能接受邮件。另一个是common name，它代表你的证书要代表的目标，如果为你网站申请的证书，就要填写域名。如果为了https申请，这个必须和域名吻合，否则会引发浏览器警报。生成的csr文件交给CA签名后形成服务端自己的证书
4. crt生成方法
CSR文件必须有CA的签名才可形成证书，可将此文件发送到verisign等地方由它验证，要交一大笔钱，何不自己做CA呢。
openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey server.key -CAcreateserial -out server.crt
输入key的密钥后，完成证书生成。
-day: 证书的有效期，单位是天，默认是365天
-CA选项指明用于被签名的csr证书，
-CAkey选项指明用于签名的密钥，
-CAserial指明序列号文件，
-CAcreateserial指明文件不存在时自动生成。
最后生成了私用密钥：server.key和自己认证的SSL证书：server.crt
证书合并：
cat server.key server.crt > server.pem（注意这里文件权限都要修改一下）
