申请https证书相关说明

当下的互联网应用如果是外网访问，一般都是https方式访问，需申请https证书

Why https ？
What is https？
- 1. A 通过浏览器访问 B 服务端443端口，并随身携带如下信息一并传递给B
- 2. B 收到A发来的携带信息，B 将做如下几件事情：
- 3. A 收到 B 发来的https证书，将验证证书的合法性
- 4. A 验证证书合法后，将下面的信息发给B
- 5. B 得到 A 发过来的信息做最后的回应
How to create https ？

Why https ？

http 明文传输不安全，因此需要进行加密处理，加密后端http就是https

What is https？

https 涉及很多概念，对称非对称加密、CA、数字签名、证书等等。

有兴趣查看这里漫画解说https 这个只能快速了解https大致原理。
建议查看 https加密原理 https://www.jianshu.com/p/cf2f86bc597a ，内容比较多比较细，但很多点讲解到位。

这里简要总结：
A (客户端浏览器) ------通过 https://www.xxx.com 访问------> B（服务端网站）

1. A 通过浏览器访问 B 服务端443端口，并随身携带如下信息一并传递给B

携带项	说明
随机数1	最后用于生成AB之间对称加密的密钥
自己支持的 SSL 版本号	比如TLS 2.0版
自己支持的加密算法	对称加密和非对称加密
支持的压缩算法

2. B 收到A发来的携带信息，B 将做如下几件事情：

事件项	说明
确认使用的加密通信协议版本	比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信
将生成一个随机数2发给A	最后用于生成AB之间对称加密的密钥
确认使用的加密方法	比如RSA公钥加密
将https证书（Certificate）发给A	该证书从CA（全球权威证书颁布机构）申请
支持的一些SSL/TLS扩展

------------->>>>> 关键问题1：B 的证书哪里来的？
答案是从CA（权威证书颁布机构）申请的，CA颁发给B的证书中包含了如下信息：

包含项	说明
颁发机构	例如是 Let’s Encrypt
B的域名	www.xxx.com
证书有效期	有效期从 yyyy-MM-dd 到 yyyy-MM-dd
经过CA私钥加密后的B的公钥	A需要通过CA的公钥解密才能最终获得B的公钥
经过CA私钥加密后的数字签名	数字签名是A用来验证该证书是否合法是否被篡改等

3. A 收到 B 发来的https证书，将验证证书的合法性

------------->>>>> 关键问题2：A 浏览器如何校验 https证书的有效性？

 (1) 浏览器内置了各大颁发机构的公钥，通过证书中的颁发机构找到对应的【CA公钥】(2) 浏览器用【CA公钥】解密CA私钥加密后的数字签名得到 【密文信息1】这里说明一下 【密文信息1】是CA对【B的公钥】【B的域名】等信息整合在一起，进行数字摘要算法（例如MD5算法） 所获得的。(3) 浏览器用【CA公钥】解密CA私钥加密后的B的公钥得到 【B的公钥】(4) 浏览器用和CA相同的数字摘要算法对【B的公钥】【B的公钥】【B的域名】等信息进行相同的数字摘要 从而生成【密文信息2】(5) 对比【密文信息1】 和  【密文信息2】是否一致一致则验证通过，否则失败，证书不可信。另外浏览器还会校验证书的有效时间和域名匹配等。

4. A 验证证书合法后，将下面的信息发给B

发送项	说明
随机数3	用【B的公钥】加密，防止被窃听 , 该随机数也是用于AB之间对称加密的密钥
编码改变通知	表示随后的信息都将用双方商定的加密方法和密钥发送
握手结束通知	表示客户端的握手阶段已经结束

5. B 得到 A 发过来的信息做最后的回应

发送项	说明
用B的私钥解密A发来的加密随机数3	此时 A 和 B 同时具备了上面步骤中的 3个随机数，按照编码改变通知指示生成一个对称加密密钥（例如 DES AES等）
生成一个 New Session Ticket	类似于sessionId AB之间不可能每次都认证加密解密，因此一段时间内同一个 Session Ticket 下将不再进行重复的认证过程
服务端传输改变通知	表示知晓加密方式，加密密钥，准备开始传输报文
服务端发送第一个加密报文

. ------------->>>>> 关键问题3： A如何生成对称加密的密钥？如何发给B ？
问题 1 答案
根据上面的流程1、2、4 可知A不是只简单生成一个随机数发给B，
而是集三次随机数（A 发送2个随机数给 B，B发送1个随机数给A）于一体，通过协商的一致算法生成一个对称加密的密钥进行通信。

这里的对称加密密钥生成算法比较复杂一些，不是我们通常认知以为就是一个简单的随机数，具体查看相关文档，这里只做简单记录。

问题 2 答案
对称加密密钥不用发给B，A和B都有了相同的三个随机数，A和B 都会用DH算法计算出一个master secret，这个master secret就是对称加密密钥。

一片不错的文章参考： https://blog.csdn.net/qq_31442743/article/details/116199453

以上步骤中，黑客想要中间截胡伪造B的证书给A是几乎不可能的，因为无法获得CA的私钥
A浏览器只会用CA的公钥对证书解密获得签名信息，验证域名，比对签名信息，验证有效期等，
如果A非要使用非权威机构CA颁发的证书，那就没办法保证安全了，浏览器一般标红或阻止访问没有经过权威机构CA颁发的证书的网站。

How to create https ？

要想http 访问方式变成 https 网上流程说明很多，总结一下主流步骤：

准备好经过认证后的域名
去权威网站（如 Let’s Encrypt 或各云平台）申请域名对应的https证书
配置你的应用服务器（如nginx）将获得的https证书文件集成到应用中
配置监听443端口，重启应用服务器，刷新浏览器

这里说明一下，之前说的什么生成CSR文件然后去CA怎么怎么搞的都老土了！
CSR即证书请求文件，就是根据提供的公钥私钥，一堆公司地址信息等，到CA申请证书一般很多卖https证书的网站都一套连搞定了！

例如在nginx中配置相关信息，类似于下面【server】区域的配置：

# HTTPS server#server {listen       443 ssl http2;server_name  www.xxxxx.com;ssl_certificate /apps/nginx/fullchain.crt;ssl_certificate_key /apps/nginx/private.pem;ssl_protocols TLSv1.1 TLSv1.2;ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;ssl_prefer_server_ciphers on;ssl_session_cache shared:SSL:10m;ssl_session_timeout 10m;location / {root   /apps/nginx/html;index  index.html index.htm;}

其中的：

        ...ssl_certificate /apps/nginx/fullchain.crt;ssl_certificate_key /apps/nginx/private.pem;...

里面有 fullchain.crt; private.pem; 这两个文件，这到底是什么？还有一般云平台提示私钥格式不正确,请提供RSA格式的证书错误是怎么回事？

这里先列出一般免费https证书网站申请通过后，下载下来的压缩包中的文件种类说明：

文件	说明
private.pem	私钥，可更改后缀为key
fullchain.crt	包含了公钥的CA证书，可更改后缀为pem
certificate.pfx	IIS和Tomcat使用，秘钥在detail.txt中
certificate.crt	域名证书，一般不用

SSL/TLS 小知识点：

SSL/TLS  是一种安全加密协议， TLS是SSL的标准化、升级版本（SSL存在一些缺陷）SSL目前有三个版本，SSL1.0、SSL2.0、SSL3.0，因其存在严重的安全问题，大多数公司目前均已不在使用了。TLS目前也有三个版本，TLS1.0、TLS1.1、TLS1.2，TLS目前只是草案，并未面世，目前常用的为TLS1.2，server配置通常三个版本均支持

报 “xxxRSA格式的文件xxx”错误时没有弄明白 RSA 几种加密形式
其实就是 RSA私钥格式PKCS1和PKCS8之间的相互转换

参看 https://www.jianshu.com/p/08e41304edab

一般 PKCS1格式文件内容如下：

一般 PKCS8格式文件内容如下：

PKCS1/8 小知识点：

借用网上的评论：
通俗点讲吧，PKCS1是标准RSA秘钥对标准规范，但是都是裸奔的；PKCS8是对加密后的秘钥进行了描述，就是说P8格式的秘钥不是裸奔了