Https&证书

参考

• http站点转https站点教程
• http站点转https站点教程
• HTTP与HTTPS的区别

Http站点转为Https：

• 为域名购买/申请证书（免费型DV SSL）
• 把证书部署到web server（有可能申请证书后生成TXT时就要选）
• 注意要是443端口
• 注意最好保留http，即让http开头的请求也进来，可能要配置http跳转到https
• 注意js，css，图片等等链接也要换成https，因为加密网页内如果有非加密的资源，浏览器是不会加载那些资源的。

Https握手

• 如果服务器端用的是购买的证书，那么一般这个CA机构的公钥已经内置在操作系统中，供用户验明证书时使用。
• 如果像12306那样用的自签名证书，那么通常需要浏览器端自行导入公钥，用于验明证书并认为你已经信任它了。

总结

• 演进过程
  • 怎么让网络传输的内容不能谁都能看懂？用对称加密。
  • 怎么不在网络上传输密钥？用非对称加密可以不传输私钥，只传输公钥。
  • 怎么不在网络上传输公钥？用CA自己证书里的公钥去验证网站的证书中的公钥。
    • CA是提供证书认证服务的公司，网站的证书需要向其购买
    • CA 用自己的私钥给用户网站的公钥签名，这就相当于给用户网站背书，形成了用户网站的证书。
    • CA 的证书/秘钥是用户手动导入或者内置在操作系统或浏览器中的，CA是大家都信任的。
    • 通过这种方式，我们访问用户网站时，得到的不再是一个公钥，而是一个证书。这个证书里有发布机构 CA，你只要通过这个 CA 的公钥去解密用户网站证书的签名，解密成功，Hash 对的上，就说明用户网站的公钥是真实可信的。
• 证书的使用过程
  • 也就是说电脑、浏览器中预置或者导入的是CA的证书！！！用这个证书来验证以https方式访问网站时网站所提供的证书！！！
  • 客户端的证书是CA的证书，用来验证服务端网站通过HTTPS握手提供的CA颁发的证书是有效的，真的是这个CA颁发的，但客户端还要自己的代码逻辑中再检查一下Subject和Subject Alternative Names字段，确认这个证书不仅有效而且就是这个网站的，这个过程如果客户端是浏览器，浏览器会帮忙做。
  • 对于一些特殊的操作系统或者非电脑设备，有可能没有预置的CA自身的证书，这是需要手动导入或者放到某个特定的地方给需要的程序使用。
  • 对于单向的认证如客户端认证服务端来说，客户端程序代码中可以使用OpenSSL进行证书的认证，在证书的verify时可以以匿名函数等方式传入验证逻辑。验证逻辑通常是验证服务器端提供的证书中的host（Subject字段），但是还应该认证SANs字段（Subject Alternative Names）字段中提供的多个域名，这是pem格式的x.509 v3证书提供的标准扩展字段，用于企业级多域名使用同一证书进行验证的情况（省钱？不用每个域名搞一个证书？因为Subject字段一个证书只有一个）。
    • Subject和SANs字段中的域名不是模糊匹配的，必须包含所有级别的域名，比如对于https://gateway.cn1-pre.mindsphere-in.cn/api/agentcom-mcapps/v3/ws11/message11.wsdl来说，.mindsphere-in.cn无法匹配，必须CN或SANs中有.cn1-pre.mindsphere-in.cn
    • 也就是说客户端代码在使用OpenSSL库验证访问的网站的证书时，不仅要检查所访问的网站的域名在不在证书的Subject字段中，还应该检查在不在SANs（Subject Alternative Names）字段中（可能要pem格式的证书才行？x509 v3？？）。
    • 
    • 
  • CA的证书可以在浏览器的content或security中查看，网站提供的证书可以在地址栏左侧的安全锁图标上点击查看（也可以选中上级的各级CA来查看他们自身的证书），还可以导出这些各级的证书。
• 自签名的证书是指不是CA颁发的证书，访问网站时浏览器会提醒不安全
• 证书的验证类型分为域名验证（DV，有权使用该域名，浏览器地址栏显示为绿色的锁，点击后不显示组织信息）、组织验证（OV，申请较慢，进一步认证该公司/组织的信息，点击加载证书后可以看到组织信息）、扩展验证（EV，申请最慢，进一步确认组织是否知道有人申请证书并且获得了授权，地址栏会显示一个锁和公司名）。
• 客户端和网站各有一对公私钥，用于各自数据的加解密，自己保存私钥，公钥给对方使用。
• 客户端的公私钥通常是自己用算法生成的（OpenSSL提供了这个功能，并且提供了通过算法进行验证的功能），网站的公私钥对通常是颁发证书的CA提供的。
• HTTPS解决的就是如何安全的交换公钥，CA自身的证书/密钥通常是内置在操作系统或浏览器中的，或者用户手动导入根证书（说明你人为得信任它）
• CA颁发的证书通常是跟域名绑定的，并不认服务器什么的，还是要看是哪一种证书？？？是不是最基本的证书已经需要认证域名了？？？
• CA提供证书是收费的，即使同一家CA公司在不同的地区可能是不同的子公司提供证书，有可能CA自身的根证书是不同的，有可能需要手动导入
• 签发证书的服务并不是谁都能提供的，即使是一家大公司，如果不是专业的CA，如果被黑客攻克，有可能客户端安装的根证书或者颁发的证书会遇到吊销等问题
• HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
• 想要理解HTTPS，就要用倒推的方式来理解为什么要那么步骤
• https中间人攻击，其实并不是真正意义上的攻破了https，还是可以看出来的，比如请求的https地址变成了http，或者浏览器提示说证书不可以或无效
  • 因为向CA购买的证书，只有你拥有，必须部署在自己的服务器上，用户在浏览器上的页面上看到的证书并不全。因此只是DNS劫持等方式伪装中间人，用假的或者申请的别的证书，证书其实还是无效的，CA在审核时会审核域名是否真的属于你。