随着苹果和腾讯微信小程序强制要求HTTPS安全通信，以及免费证书LetsEncrypt的出现，安全证书（下文简称证书）的部署已成为必选项，其部署成本也大为降低。正确部署了证书后，能大幅减少网络嗅探带来的安全问题和提高用户隐私的保护程度。但如果证书部署不正确，其本应具有的安全性会大打折扣，甚至形同虚设。下面就在高校中如何配置安全证书尝试做一个“最佳实践”的探讨（不探讨加密算法等原理）。

　　高校中的重点保护对象

　　在高校里，一般需要给这些服务配置安全证书：统一身份认证&单点登录服务、邮件服务、SSL-VPN、部分安全性要求较高的Web应用（如财务系统、科研系统等）、一些需要在手机APP内或微信小程序内调用数据的Web应用等，若有必要的话，也可以考虑给HAProxy（负载均衡前端）、WWW门户、FTP等服务配置证书。

　　目前高校统一身份认证&单点登录服务常用的架构是CAS/Shibboleth+LDAP，部分高校还有基于oAuth的认证授权为一体的服务。其中，CAS/Shibboleth/oAuth都走的是HTTP协议，传输的是用户名密码等高度隐私数据，被第三方系统调用频率很高。所以应将其作为第一个优先部署证书的服务。后端的LDAP认证系统一般会部署在内网，但若要防范内网攻击源，也需要对其部署证书。

　　邮件服务的使用频率非常高，也容易受到攻击。邮件服务一般会同时开放Web、IMAP、POP3、SMTP等访问协议，需要同时在这些服务上配置证书。

　　值得注意的是：域名系统安全扩展（DNSSEC）的证书体系虽然和本文中的基于X.509协议的证书体系有些不同，但在配置时也可以作为参考。

　　另外，从信息安全等级保护工作角度来看，可能对于等保定级为2级以上的业务系统最好都需要配置安全证书。

　　证书服务商的选用

　　值得推荐的是LetsEncrypt免费证书。LetsEncrypt的赞助商是谷歌、Facebook、Mozilla基金会、Cisco、Akamai（CDN服务商）等巨头，所以其服务的长期稳定性也是可以保障的。LetsEncrypt提供了Apache/Nginx等服务器端证书自动生成工具，非常方便高效，可配合cron工具自动续期证书。对于SMTP/IMAP/LDAP等服务的配置也可手动完成。但LetsEncrypt无法为个人签发数字证书，若有需要对邮件、电子印章进行证书签名的使用场景，则不能选用它。此外，目前由于绝大部分购买的SSL-VPN是硬件式设备，若需要将LetsEncrypt证书应用到其上，需要咨询厂家是否支持LetsEncrypt证书的自动续期，否则，维护起来比较麻烦。

　　另外，由于市场占有率排名第一的Chrome浏览器逐渐不再信任赛门铁克及其旗下的SSL证书，若要选购商业证书，需要确认服务商不在黑名单中。

　　证书配置过程中的注意事项

　　生成可靠的私钥

　　一般选用加密长度为2048的RSA算法生成私钥，1024位被破解的风险较大。一旦私钥被破解，证书体系的安全性全部丧失。若在向证书服务提供商申请证书的过程中允许由自己来生成私钥，在执行相关OpenSSL命令时，尽可能通过不停随机敲击键盘来增加随机熵值。

　　选用安全的证书协议

　　有五种协议SSLv2、SSLv3、TLSv1.0、TLSv1.1和TLSv1.2（SSLv1从未公开发行），其中TLSv1.1和TLSv1.2目前还未发现有安全问题。大家习惯上把安全证书称为SSL证书，但恰恰SSLv2和SSLv3这两种协议都是不安全的，严禁使用。TLSv1.0也有些小问题，但为了兼顾一些老式的通信对象，可以使用。在默认配置中，也应不启用TLSv1.0，当发现不兼容问题后，若第三方应用无法更改，可再启用TLSv1.0。

　　使用完整的证书链

　　证书链可简单理解为操作系统或浏览器内安装的全球根证书、终端用户证书以及这两个证书中间的一级或多级证书服务提供商的证书之间形成一个环环相扣的信任链，如果中间缺了某一环，则证书链不完整，也就不能确保证书安全。实际配置过程中，管理员有时候会直接把从证书服务提供商处下载的服务器证书文件配置到Apache等配置文件中，忘记将证书提供商的中间证书也要放在证书文件里，就会导致证书链不完整的问题。一般来说，直接把服务器证书和提供商的中间证书合并在一个文件中即可（都是文本文件）。

　　配置恰当的加密组合

　　加密组合是指证书安全体系中的协议、密钥交换算法、AES加密算法及其分组加密模式、摘要哈希算法的组合。需要兼顾安全性、通信对象的强制性和兼容性、性能等因素，一般将安全性高的加密组合放在前面，大部分通信对象会使用匹配到的第一项组合，忽略其他组合。

　　保障OpenSSL的安全更新

　　应设置系统自动安装安全更新，特别是OpenSSL及其相关库（如libssl等）的安全更新。OpenSSL的安全漏洞往往会导致证书的安全性变得极为脆弱。

　　Web应用中常用的证书相关问题和配置

　　由于大多数软件基础设施和业务系统都是Web应用，所以对此做侧重探讨。

　　1.HTTPS Web应用中引用了非HTTPS的外部服务器链接。常见情况是引用了外部的HTTP链接的JS/CSS，此时Chrome浏览器证书标识小锁图标上就会显示黄色三角形，如下图：

　　此时，应优先改为本地引用，或者直接引用无安全问题的HTTPS外部链接。

　　2.安全Cookie配置。开发人员一般习惯于不加密直接读写Cookie，尤其是当存储了HTTP Session数据的Cookie被不法者拿到后会用于中间人攻击。我们需要在Web服务器内启用安全Cookie，这样，Web服务器就会拒绝不是由浏览器发出的Cookie。如Apache的配置是：Header edit Set-Cookie^（.*）$$1；HttpOnly；Secure

　　3.启用HTTP严格传输安全（HSTS）配置。当Web服务器中的证书配置有误时，HSTS仍能指示浏览器保障安全通信，浏览器也不会提醒用户忽略警告继续访问（最常发生于证书过期时）。如Apache的：Header always set Strict-Transport-Security“max-age=15768000”

　　4.对非敏感性资源启用客户端缓存。WWW门户访问量一般很大，若要对其配置证书，需要启用图片等非敏感性资源的客户端缓存以提升性能，一般需要在Web服务器内做相关设置，如Apache的：

　　<FilesMatch   "\.(ico|pdf|flv|jpg|jpeg|png| gif|js|css|swf)$">

　　Header set Cache-Control“public”

　　对于配置了自签名的证书的应用则不可启用HSTS，否则用户无法忽略安全警告和继续使用服务。

　　高校环境中常见的兼容性问题

　　1.WindowsXP中IE8及以下版本浏览器不支持新式的加密算法，若必须要支持，需要启用RC4加密算法，Web服务器端需在加密组合的配置中添加RSA-WITH-RC4-128-SHA和RC4+SHA。显然，这会降低证书的安全性，所以优先做法是说服用户升级操作系统和浏览器。

　　2.JRE/JDK6中的Diffie-Hellman加密算法的加密长度最多只能支持1024位，导

　　致无法和2048位的证书通信，从而出错。这类问题最常发生在基于JDK6开发的应用在和单点登录系统对接时，而升级JDK又造成应用无法正常使用。这种现象在部分高校应用系统中比较常见。此时，我们只能动“小手术”，将JDK6的Security Provider改成Bouncy Castle Provider（可从http：//repo1.maven.org/maven2/org/bouncycastle/中下载bcprov-ext-jdk16-1.46.jar和bcprov-jdk16-1.46-javadoc.jar并作适当配置）。

　　相关工具

　　运用以下几个工具能减少出错机率，让配置工作事半功倍。

　　1.SSLLabs证书安全性在线检测和诊断工具https：//www.ssllabs.com/ssltest/：一般B级及以上才可视为具有足够的安全性。建议高校同行都使用该工具检测一遍学校的证书的安全性。在诊断结果的“HandshakeSimulation”小节中可看出通信对象的兼容性，可帮助预判兼容性问题，在移动互联网时代，特别要注意移动设备的兼容性。也可以利用该工具查看国内大型网站和美国高校的证书配置，可学习借鉴其如何处理安全性和兼容性的做法。

　　2.服务器证书配置文件生成工具https：//mozilla.github.io/server-side-tls/ssl-config-generator/：可生成Apache/Nginx等服务的配置。优先考虑使用Modern类型的配置（其中，Apache需要2.4.*版本才支持Modern类型）。

　　3.在线完整证书链生成工具https：//certificatechain.io/

　　（作者单位为上海外国语大学）