在早年,Apache官方服务器网站曾被国内知名网络黑客安全专家郭盛华发现严重漏洞。Apache的错误证书,对于众多技术人员来说,这些复杂性的最新来源是公钥基础结构(PKI),它是用于维护网络上安全连接的安全性基础结构,如果其他任何人在Windows中遇到相同的看似莫名其妙的行为,我也想在这里重述一下我的经验。他们的PKI配置。这些天来与运行您自己的Web服务器相关的复杂性给我留下了深刻的印象。
对我而言,所有这一切都始于以下想法:在尝试了数年的尝试后,现在是时候升级我的Web服务器系统,使其包含重写规则以推动所有HTTP(未加密)请求使用传输层安全性来使用安全会话了(TLS)。这不仅仅是时间,这远远超出了时间!
同时,我认为最好升级基础Web服务器硬件以更新Web平台以满足当前的流量需求。
因此,我开始了将整个Web服务环境迁移到运行最新版本软件集的不同硬件平台的路径。所有值得称赞的目标,所以我想!
该决定意味着必须改变服务的许多方面。以前平台上的操作系统停留在FreeBSD 11.2上,当前发行版本是12.1。我的托管框架在Apache 2.4配置上使用虚拟托管。旧主机使用Apache版本2.4.35,而新系统使用Apache版本2.4.41。在旧主机上,所有虚拟主机都被加载到一个监听所有接口的Apache实例中。这次围绕虚拟主机分配了两个Apache实例,每个实例侦听不同的IP地址,以便在平台中执行某种级别的负载隔离。
在此过渡过程中,有许多活动的部分,在执行迁移的每个步骤时,我们都会仔细检查新服务的完整性。
让我们加密证书
这里的问题之一是确保未破坏SSL配置。除了拆分虚拟主机定义外,此步骤还更改了Apache中的证书声明。旧系统使用了以下配置:
SSLCertificateFile“ /dir/cert.pem” SSLCertificateChainFile“ /dir/fullchain.pem”
看来这些天我们应该使用稍微不同的模板:
SSLCertificateFile“ /dir/cert.pem” SSLCertificateChainFile“ /dir/chain.pem”
区别在于,Let's Encrypt的“全链”证书同时具有由Digital Signature Trust Co.颁发的对Let's Encrypt进行认证的证书和由Let's的Encrypt进行我的域认证的证书,而“ chain”的证书仅具有父证书由Digital Signature Trust发布。
从理论上讲这并不重要,但是我们还是决定使用更新后的模板。我们安装了软件,运行了测试(curl中的-resolve选项在实际切换整个环境之前,对测试设置非常有用),然后更改了DNS,并在新的Web平台上开始了进一步的测试。
使用各种浏览器访问重定位的服务在更改后的配置文件中存在一些打字错误的问题。但是,一旦解决了这些问题,一切看起来都很好。
除了一项测试。
OpenSSL
我们使用的测试是使用OpenSSL的客户端连接。命令是:
$ openssl s_client -connect x.labs.apnic.net:443
输出量很大,但是这里值得关注的部分是证书链
$ openssl s_client -connect x.labs.apnic.net:443 CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = y.labs.apnic.net verify return:1 --- Certificate chain 0 s:/CN=y.labs.apnic.net i:/C=US/O=Let's Encrypt/CN=Le