HSTS(HTTP Strict Transport Security)
通过Web服务器上的设置，在收到HTTP访问请求时，返回的header里带有Strict-Transport-Security字段，告知浏览器必须使用HTTPs进行访问。
但是，HSTS并不能避免首次跳转时遇到的劫持。要彻底解决这个问题，可以申请加入Preload List(预加载列表)。
Preload List是由Google Chrome维护的“HTTPs站点列表”，Chrome, Firefox, Safari, Edge, IE 11均在使用。一旦浏览器发现要访问的站点在Preload List上，默认就会发起HTTPs链接。这样，就避免了HSTS的首次跳转被劫持的隐患。
SSL卸载
采用F5来做负载均衡，F5应付单纯的L4和L7的流量是没有问题的，但进行SSL卸载时性能往往会急剧降低，F5可以提供专门的加速卡来解决这个问题，但价格不便宜。所以，还需要专门环节来进行SSL卸载，常见的Nginx和HAProxy都可以执行这个任务。
客户端证书
与浏览器不同的是，C#信任的根证书在localmachinestore或者currentuserstore中，Java信任的根证书在JDK安装目录下的cacerts目录中，iOS和Android的证书管理又有不同。
浏览器的证书在使用中又可以持续更新，用户往往感知不到，如果“想当然”认为浏览器验证通过就万事大吉，很可能会出问题。比如国内有不少网站使用WoSign签发的证书，但老版本的JDK并不信任WoSign的根证书，用浏览器浏览没问题的网站，程序就会报错，除非手动导入证书。Android的信任列表是随固件更新而更新的，4.2以后才内置WoSign的信任。因为WoSign行为不端，前几天Firefox, Chrome, Safari等主流浏览器又取消了对它的信任，也就意味着WoSign证书有安全风险，所以已经内置WoSign根证书的程序也应当做对应的设置。
服务器端证书
用浏览器验证没有问题的HTTPs站点，用程序访问就有问题。这是为什么?
在服务器上证书配置错误，只有最终证书，而缺少中级证书的情况。通常，最终证书里包含了中级证书相关的信息，所以如果缺少中级证书，浏览器为了建立证书链，会做一次耗时的操作来获取中级证书，而且这一切都发生在HTTPs连接真正建立之前。更糟糕的是，不少浏览器为了“表现更好”，会想办法绕过这个问题。所以缺少中级证书的情况一直存在，一直不会被发现，而程序调用的速度总是上不去，甚至有一定几率报错。
证书大小：
如果把证书链配置完全，还要注意证书链的大小。有一些网站的完整证书异乎寻常地大，达到若干kb甚至几十kb，也就是说，在建立连接之前，就必须先传输这么多的数据。如果做单纯的PC网页浏览，或许不会有问题。但对于移动端和程序调用来说，这就是一场灾难。最好的办法，是用OpenSSL配合WireShark之类的工具，自己动手来测试。如果你熟悉TCP相关的知识，往往可以得到更好的优化方案。
OCSP和CRL也不可忽略。这两项技术用来保证撤回证书(让证书失效)的有效性。如果你仔细观察，会发现证书里都指定了对应的OCSP或者CRL的URL，用来检查证书是否失效。按道理说，在每次建立HTTPs连接时，都应当进行OCSP或CRL检查。返回结果通常在1k左右，如果请求非常频繁，这个因素也应当考虑。
SNI
大家都熟悉“虚拟主机”的概念，它可以让多个域名对应到同一个IP，让同一台服务器服务多个站点。在HTTP时代，可以在header中通过host来指定需要访问的域名，一切看起来都那么完美。
但是在HTTPs时代，却没有这样的好事，传统的HTTPs服务很难让多个域名对应到同一个IP。在进行到HTTP通讯之前，必须先建立验证证书建立连接。如果一个IP上绑定了多个域名，这个阶段服务器根本没法知道请求对应的是哪个域名，无疑会造成极大的不便。
为了解决这种问题，SNI(Server Name Identification)应运而生了。这种技术说起来复杂，大家可以把它简单理解为“建立SSL/TLS通讯时的host header”，这样就解决了一个IP只能配单张证书的问题。
然而SNI的诞生历史并不长，许多客户端的支持都存在奇怪的问题。比如JDK7支持SNI，但是JDK8的支持又有bug。而且这种支持往往需要调用原生的API才可以实现，Resteasy之类的类库并不支持。如果对SNI的支持有问题，即便配置正确也可能无法建立连接，因为服务端并不能识别此请求需要的证书。
CDN
CDN已经是业界流行的技术了，对稍微大一点的网站来说，没有CDN几乎是不可想象的。HTTP时代的CDN方案相当成熟，HTTPs的情况则不是如此。
要使用HTTPs的CDN服务，就要决定是否将证书交给CDN提供商。基于中国目前的商业信誉水平，把证书交给CDN提供商的风险不可不考虑。恶意揣测，别有用心的人一旦拿到证书，可以很方便地通过DNS劫持发起中间人攻击，而完全不被感知到。
另外，HTTP时代大家都喜欢将资源分散到多个不同的域名，因为建立连接的成本很低，而同一个域名的并发连接数有限。在HTTPs环境下，每次建立连接的成本高了很多，频繁下载和验证证书对移动设备和移动网络影响很大(尤其是证书很大的情况)。如果域名非常分散，影响就更加显著。所以在HTTPs时代，把域名收缩集中反而是更好的办法。
内容及其它
因为HTTPs的内容中无法引用HTTP的资源，所以应当保证网页中资源文件的链接都是HTTPs的。遗留的许多系统很可能并不注意这些事情，资源都采用绝对地址的形式，这样改起来工作量很大。如果要修改，最好一步到位，直接改成“协议相对URL”。
绝对地址URL：http://www.a.com/b.css
协议相对URL：//www.a.com/b.css
这样浏览器就可以根据当前的协议，自动生成资源的绝对地址，无论是HTTP还是HTTPs，都可以自由切换。
如果资源都是自有的，切换HTTPs就相对容易。如果存在外部，尤其是UGC的资源，切换到HTTPs就很麻烦。如果是超链接，通常采用专门的跳转服务，也就是下面这样：
https://link.my.com/target=www.you.com
如果是图片这类资源，可以设定专门的程序将其抓取过来存放在自己的服务器上，再将地址替换掉即可。但是，这样做很可能要自己承担流量压力，同时还要承担恶意程序攻击的风险。
如果是视频、游戏等富文本、交互复杂的资源，如果源站没有提供HTTPs的服务，多半只能忍痛割爱，放弃内嵌展现的形式了。