[每日短篇] 24 - HTTPS 和 SSL 自签名证书的现代知识

今天因故须要测试 SSL 自签名证书，在翻阅资料时发现中文社区介绍 HTTPS 和 SSL 证书的网帖不只陈旧并且存在很多同源的错误，一旦错误内容处处都是就容易被人当成正确的，因此写一篇帖子更新一下现代知识和更正一些错误观点。如今是 2019-11-06，若是好久之后看到这篇帖子，其中与协议版本、密钥强度相关的内容已通过时了，请注意识别。

关于 HTTPS

• HTTPS 是 HTTP 的扩展，重点解决传输安全的问题，之前是 HTTP over SSL，新的是 HTTP over TLS。须要注意的是 HTTPS 解决的是传输安全，防范窃听、中间人攻击之类的，不解决两端的安全问题，见过一些系统中试图用 HTTPS 解决防客户端破解的问题，其实是没有任何用处的。
• 通常场景下只有客户端验证服务器的证书，客户端不向服务器提供证书。对安全性要求特别高又高不到须要额外硬件支持的时候，还能够双向验证证书，好比早期的网银、支付宝会须要申请数字证书，本身下载安装以后，登陆时须要向服务器提供证书验证客户端身份。

关于 SSL 和 TLS

• SSL 和 TLS 也有多个版本，按照 Google、Mozilla、Cloudflare 等大厂的认识，为现代客户端提供的服务应该使用 TLSv1.3，为远古客户端提供的服务应该向下支持到 TLSv1，为不太古老的客户端提供的服务可使用 TLSv1.2 TLSv1.3。这跟国内情况差异巨大，国内还在大量使用远古客户端都不该该支持的 SSLv3，要是用到 TLSv1.3 也常会被抱怨版本过高。
• 密钥位数如今推荐 2048 位，1024 位的现代浏览器都会吐槽不安全。
• SSL 证书有几种分类方式，其中一种是根据域名格式分的，*.xxx.yyy.zzz 叫作泛域名证书，不包含 xxx.yyy.zzz 自己。
• SSL 证书支持对 IP 签发，与对域名签发同样，签发以后任意端口可用。
• Cipher 也分强弱，TLSv1.2 里也有弱密钥算法，要用 TLSv1.2 的话 Mozilla 推荐 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384，TLSv1.3 目前看都还行。
• 在 Nginx 里若是只用 TLSv1.3 的话，不要添加 ssl_ciphers 指令，即便指定的是 TLSv1.3 的几个 cipher 也照样报错，不写就没错了。若是是同时用几个版本，也不须要在 ssl_ciphers 里面写 TLSv1.3 的 cipher。
• 签发一个证书不会让另一个证书失效，在一个新服务器上使用证书也不会让老服务器上的同一个证书失效。CA 那里有让证书失效的机制，第一须要人为申请，第二须要客户端知道要到网上查且能到网上查某个证书的有效性，因此这个机制并不老是可以生效。

关于自签名

• 不少网帖里面（包括英文帖子）提到自签名第一步生成私钥时须要输入密码，而且还要第二步去掉密码，实际上罪魁祸首是命令里面的 -des3，这个参数的做用是用 DES3 加密私钥，那不要密码就怪了。蛮奇怪第一个这么写帖子的人在想啥，后面的人抄的时候在想啥。
• 若是没加 -des3 也要输入密码，试试 -nodes 参数，有些系统缺省参数不同，可能须要显式禁用加密私钥。
• 自签名密钥也记得改 2048，强度跟是否受信是两码事。
• 访问自签名网址时注意看浏览器的风险提示，是这个证书是自签名的仍是这个证书跟域名不匹配，提示是自签名的服务器就配置对了，否则就还得继续改。