目录
一、HTTP(HyperText Transfer Protocol)
二、HTTPS(Hyper Text Transfer Protocol over SecureSocket Layer)
3、tomcat安装证书，tomcat需要jks证书（crt证书要先转为p12类型的证书在转为jks类型）
一、HTTP(HyperText Transfer Protocol)
HTTP（超文本传输协议）是普遍使用的一种应用层协议，超文本意味着它能传输文本以外的资源，例如音频、视频等，对于前端开发人员来说是最常接触的协议，熟练使用它也是必备技能之一。
谈到HTTP就要说下GET和POST了（GET和POST能组合出其余所有的类型，例如PUT，DELET等），常见的理解是像账号密码之类的最好能使用POST，因为放到GET里会显示在导航栏内，不安全，但使用POST就一定安全吗？
无论使用GET还是POST都无法避免一个问题，HTTP是明文传输的，数据放到哪里都有被看到的可能性。
有时候我们会看到有些网站里会有小广告，这些广告商好像很厉害，能让任何一个不起眼的网站帮它展示，事实上网站拥有者可能并不清楚这些广告的存在，而这种出现广告的网站很大可能使用的是使用HTTP传输的，因为使用了HTTP，所以是明文传输的，因为明文传输，就有因为传输时流量被劫持广告被加到网站内可能性，尤其是想要网络通信就必须通过运营商的路由，而电信、联通、移动四大运营商是具备劫持流量的能力的，因此有许多烦人的弹窗小广告可能并不是出自建站者的本意。
而且有些信息杯被篡改不说，可能连被看到都是不合适的，因此我们就要对HTTP传输的数据加密了，HTTPS就产生了。
二、HTTPS(Hyper Text Transfer Protocol over SecureSocket Layer)
1、HTTPS概念
HTTPS（基于安全套接字的超文本传输协议）在HTTP的基础上添加了SSL/TLS，说是SSL?TLS是因为SSL一开始是某个公司为了数据安全内部使用的，TLS是是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。也就是说HTTPS的S代表的可能是SSL也可能是TLS，现在比较常见的是TLS，出于习惯说是SSL。
2、对称加密
简单了解下HTTPS这个东西，回到前面说的给HTTP数据加密的问题，想给数据加密，好办就像压缩文件要密码一样，我用一个钥匙加密，对方也通过相同钥匙解密，这叫对称加密，加密解密使用同一个密钥，新的问题来了，我怎么让对方知道我的加密密钥。
解决密钥传输简单办法，线下传输，我们见个面我说下密码，或者给你个U盘，里面的东西能解密，事实上，银行有类似的手段，给客户一个U盘，U盘外号加密狗。但我们更多的还是线上传输，线下传输的代价与难度在很多时候都太大了，但密钥在网上传输又有传输泄漏的的可能，那和明文传输数据还是像没差别一样，因此想个办法是不是给密钥也加密下。首先肯定不能再用对称加密了，否则就成无限套娃了。
3、非对称加密
对称加密不能用了就要用非对称加密了（当然这只是为了说明HTTP加密过程的变化，我们也应能认识到是先有的非对称加密，并不是想当然的对称不能用就用非对称，为了读防止者将非对称加密与HTTPS的认知绑死，非对称加密早就用于其它地方了）。非对称密钥顾名思义，加密解密用的不是同一个密钥，有公钥，私钥之分，公钥私钥有以下特性：
- 公钥加密、私钥解密，公钥不能解密
- 私钥加密，公钥解密
- 公钥无法反推私钥
- 私钥无法反推公钥（指的是不知道对方拿的是哪个公钥）
非对称加密是基于数论产生的，由私钥产生公钥，一个私钥如何产生多个公钥具体原理可看阮一峰的对称加密讲解，里面讲解的很清楚，不过需要有些数学基础，否则很难看明白。
非对称加密常用场景（注意：私钥是不能公开的，公钥可公开）：
- 数字签名：私钥加密后公钥可解密，但是公钥加密，使用另一个或者相同公钥是解不开的，因此当使用私钥加密后，这个密文的所属者就确定了，只能是私钥的拥有者，有些合同假如说被私钥加密了，而我们能用对应公钥解开，即使对方想不认账也不行了，因此数字签名即私钥加密，公钥解密，确定密文发送者。
- 数据加密：这个用途是我们传输数据加密使用的，公钥加密，私钥解密，我们向一个持有私钥网站发送数据，传输途中，没有私钥的人是解不开的，有公钥的人也解不开，这样就确保了数据的安全。
因此借由非对称加密我们可以持有网站私钥对应的公钥对数据加密，向网站发送对称加密的密钥，可能会有疑惑，有非对称加密为什么还有用对称加密，不是多此一举吗，看上去确实是，但是网站传输要求速度，而对称加密比非对称加密的的加密解密速度快很多，因此我们拿着网站公钥加密我们的对称加密密钥，网站获取对称加密密钥后，我们就使用对称加密去加密数据。
解决到这里就结束了吗，不，还存在一个问题，网站的公钥我们如何拿到？
网站当然可以将公钥放置在自己的网站上，用户自己去获取，但这样做无疑加大了使用网站的难度，很多人并不具备这些知识的。那么网站直接在用户发起请求时将公钥发送给用户不行吗，公钥反正是公开的被拦截也没事，可以，但又有新的问题，中间某个人拦截后他没转发网站公钥，而是自己使用加密算法产生公私钥，将他自己的公钥发送给了我们，最终导致我们和他沟通，他和网站沟通。
这就叫做中间人攻击，因此我们的新问题是如何让确定公钥的来源。接下来就是HTTPS的关键了。
4、证书
证书：一般用于给某个人证书是为了证明某个人具有什么样的能力或做了什么样的事情，而颁发证书的前提是颁发证书的机构是可信的，有公众影响力的。
我们在用户和网站沟通之间是很难确立了，那么是否可借助第三方网站来证明我拿的公钥就是对面网站的密钥，第三方给网站办法证书证书里包含了网站的公钥，网站是谁，证书时效等信息，我们拿到证书就是拿到了对面网站的公钥，还能确定这个公钥确实是那个网站，我们称办法证书的机构为CA（Catificate Authority）他们的作用就是颁发证书。
如上图，谷歌火狐等浏览器的地址栏旁会有个小锁，开的状态说明是http协议，关的是https，点击小锁，或出现弹窗，再点击证书就能看到证书相关信息了，如图：
在详细信息内是能看到更多有关证书证书的信息的。
5、证书具体颁发过程
- 服务端生成自己的公钥和私钥，然后填写一张“表”，表里包含了自己的公钥，自己是谁以及域名相关信息，私钥不能填上，私钥一定要只掌握在自己手中。至于表如何生成，就要看SSL/TLS如何规定了，然后服务端将表作为证书申请书提交给CA机构，等待机构颁发证书。 可能会有个疑问，证书申请时公钥不就又在互联网上传播了吗，对所以要求我们使用CA机构的公钥对申请书进行加密，CA机构再去解密，那问题不就又会到公钥可信与否的问题上了吗，对，为了解决这个，我们电脑的操作系统其实都内置了这些CA机构的证书（在电脑内可查看的），证书里有他们的公钥。CA机构还有证书？那谁给他们颁发的呢，当然是自己给自己颁发的，所以我们才要求CA机构可信，否则的话互联网上将会再无数据安全，确实有CA机构出过问题造成了很大的数据危机的事件，有兴趣可以去查查。 说来说去可能有些绕，其实就是CA机构产生一个根证书，然后通过这个证书给自己颁发证书，我们系统内置这些证书，再用这些证书去向CA机构发起证书请求。
- CA机构收到证书请求后会验证证书里的信息是否是真的，验证成功后颁发证书给网站，指的注意的是CA颁发的证书里有自己的签名，来说明证书是谁颁发的，如果颁发机构是未知的，浏览器会显示警告信息的。并且证书里包含了一个hash值，是通过证书内容生成的，证书内容改变hash也应该变的如果根据证书内容生成的hash值与证书内的hash值不一致那么证书也应是不受信任的。
- 服务端收到证书后，通过自己内置的证书来的验证证书的合法性，每当用户发起请求是将证书发给用户，然后用户也通过内置证书来判断证书是否合法，验证过程如下：
1、验证浏览器中“受信任的根证书颁发机构”是否存在颁发该SSL证书的机构。 2、检查证书有没有被证书颁发机构吊销。 （1）CRL(证书吊销列表 该表由CA机构维护)-定期下载 （2）OCSP(在线证书检查，去CA机构那检查) 3、验证该网站的SSL证书是否过期。 4、审核该SSL证书的网站的域名是否与证书中的域名一致。 5、该网站有没有被列入欺诈网站黑名单。 6、总结来说，我们系统通过保存少量的第三方CA证书或公钥来验证更多证书或公钥的可信性。
三、在centos7的Tomcat上配置自制证书的过程
通过这个可以更详细体会到证书在HTTPS中起到的作用，以下操作皆为实际操作，但并不会讲解每个命令参数的作用以及在哪执行，想自己尝试的可以去查些资料，是可以查到的，我的也是通过自百度谷歌等搜索引擎查询的，写这个只是为了加深对证书验证流程的深刻体会。
自制证书是不被浏览器信任的因此，但如果自己了解的证书还是可以使用的，想要可信任的证书一般要交钱到CA机构获取，也可通过Let's encrypt免费获取
使用的工具是openssl，这个在linux或windows上皆可下载，它实现了SSL，并且有许多加密算法可用。
需要说明的是下面文件格式例如：pem可保存私钥，也可保存证书，只是一个文件后缀，同一份证书也会有许多格式，因为windows或linux等支持的证书格式不一样。
自制证书要先生成CA根证书，根证书一般是自签证书
1、服务器作为CA机构 生成CA根证书
（1）使用rsa算法生成2048位长的私钥
openssl genrsa -out ca-private-key.pem 2048（2）使用私钥产生证书申请请求
openssl req -new -out ca-req.csr -key ca-private-key.pem会出现要求填写的字段（有的字段可能没写出来，这些字段是来说明谁发的申请，CA机构该去验证谁的身份）
| 字段 | 值 |
| countryName | 国家名缩写 |
| stateOrProvinceName | 州或省 |
| localityName | 地点，如城市 |
| organizationName | 组织名 |
| commonName 商标 | （证书上显示的 CA 名称） |
（3）自签证书
openssl x509 -req -in ca-req.csr -out ca-cert.pem -signkey ca-key.pem -days 30（4）.pem转化为转换为浏览器可读证书格式.crt
openssl x509 -outform der -in ca-cert.pem -out ca.crt2、server端发起证书申请获取证书
（1）使用rsa算法生成私钥
openssl genrsa -out server-key.pem 2048（2）使用私钥产生证书申请请求
openssl req -new -out server-req.csr -key server-key.pem（3）使用CA证书签名（测试时server与CA根证书是在同一台服务器，因此会像自签）
openssl x509 -req -in server-req.csr -out server-cert.pem -signkey server-key.pem -CA ca-cert.pem -CAkey ca-private-key.pem -CAcreateserial -days 303、tomcat安装证书，tomcat需要jks证书（crt证书要先转为p12类型的证书在转为jks类型）
（1）在 Linux 下需要生成 pkcs12 文件，证书要求以 PEM 格式加载；
openssl x509 -in client.crt -inform der -out client.pem（2）转换证书(回车后会提示输入密码)
openssl pkcs12 -export -in server.pem -inkey server-key.pem -out server.p12 -name "mingzi"（3）p12转jks
keytool -importkeystore -srckeystore server.p12 -destkeystore server.jks -deststoretype pkcs12（4）配置tomcat/conf/server/xml文件
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/域名的 jks 文件"
certificateKeystorePassword="jks 文件密码"
certificateKeyAlias="jks 别名，一般为申请的证书域名"
type="RSA" />
</SSLHostConfig>
</Connector>配置tomcat/conf/web.xml 在</web-app>标签前配置以下代码强制访问https
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Client Cert Users-only Area</realm-name>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>SSL</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
580
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
