Certificate

Let’s Encrypt 是我目前使用的证书发证机构。早上 yegle 提到了某个bug，于是研究了一下，这里记一笔，算是留个历史见证吧。

发生了什么

在 PKI 证书体系中，信任是通过逐级签名以及对这些签名的验证来实现的。对大部分客户端系统来说，这些系统中会存在一个或多个受信的根证书发证机构的证书，其公钥是通过这些系统本身的更新机制派发的。

根证书发证机构的证书通常是自签名的，更新相对来说比较麻烦（它通常依赖于操作系统的在线或离线更新机制），因此这些证书的私钥事关重大，因此人们通常不希望经常更新它们，因而证书发证机构在绝大多数时候并不会使用这些私钥来签署证书。取而代之的是，他们会创建一些称为中级发证机构的证书用来签署日常的证书，这样根证书的私钥可以采用更为严密的方法来保护，例如可以把它们从网络上彻底断开，而中级发证机构的证书则可以以较高的频率进行密钥轮换，借此来避免其私钥暴露导致的风险。

一个新的发证机构进入市场时，其自签名的根证书往往不会被已经在市场上的客户端系统认可，因此这样一来新的发证机构想要获得用户就必须想办法解决能被用户承认这个问题。一旦获得了一定的知名度并证明了自己的可靠性，这些发证机构便可以遵循一定的流程获得主流浏览器或操作系统的认可，并将自己的根证书也加入到它们的受信根证书列表中了。所以，在起步阶段，新的发证机构往往会要求一些已经存在的根证书去对其根证书进行交叉签署，在客户端验证证书有效性时，由于这些根证书在他们看来是一个经过了受信根证书签名的中级证书而不是一个普通的不受信自签名根证书，因此也就不会给出无法验证证书是否有效的提示，而是能够正确地对其有效性进行验证了。

Let’s Encrypt 在起步阶段正是采用了这种做法。通俗地说，它的中级发证机构的证书被两家根证书机构同时签名，其一是它自己的 ISRG Root，另一个是另一家根证书机构 IdenTrust 的 DST Root X3。初期，由于 DST Root X3已经被许多操作系统和浏览器认证过，因此为其普及起到了非常重要的作用。

UTC 时间 2021年9月29日 19:21:40，DST Root X3 的根证书过期了。这样一来，这一边的信任链便不再成立。

详情参见 Google Online Security Blog。

说两个我认为比较有意思的事情：

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署，因此这类未经授权的证书本身就可以作为证据。但是，Google这样做（不公布证书）意味着签发者不得不销毁全部签发的证书，而不仅仅是被公布的那些。

有一种错误的观念是，对于不太敏感的内容（例如论坛之类），只要用 https 保护登录过程中提交密码的部分就足够了。例如国内非常流行的网易邮箱，很早以前便提供了"SSL安全登录"的选项，这样做显然是比完全不提供SSL登录选项的新浪邮箱要强多了[注1]，但是仍然是不够的。

📓 注意

2015-03-05更新：本文中部分干货已过时，本文本身也不再更新。请参阅 这张作弊条。由于 ACME 协议的普及，现时通常只需生成密钥对即可。

SSL/TLS协议中，服务器证书是用于向客户端证明服务器身份的凭据，同时它还向用户提供了服务器的公钥，而服务器公钥则可以用来建立客户端到服务器的安全通讯（具体的通讯流程要比这个复杂，纯从技术而言，服务器的公钥主要用于与客户端进行会话密钥的协商）。

服务器的公钥只能确保拥有私钥的服务器（或人）能够解密信息，但它本身并不能确认服务器的身份。在实践中有很多种不同的方法来确保公钥确实来自受信任的服务器，在通常的SSL/TLS协商过程中，采用的方法是根据证书链来逐层验证公钥是否是有效的及其身份。简单地说，就是以安全的方法（例如安装光盘，或互相认证的签名等）事先将证书链上的某一个或某几个证书发给客户端，以便其验证最终用于服务器的安全证书。关于这一流程的具体细节，已经有很多文章进行了介绍，在此不再赘述。

如此，我们在实现采用SSL/TLS的服务器的时候，需要为证书准备的事项包括：

• 找到一家被客户端信任的、具备签发证书资质的发证机构。发证机构可以是根CA（对于浏览器来说，通常可以在安全选项中找到类似"查看证书"之类的选项），也可以是这些根CA认可的二级发证机构。
• 收集用于验证服务器身份的信息，例如服务器的FQDN，等
• 生成一对用于SSL/TLS的公钥/私钥。

有了这些信息，就可以制作证书申请（CSR）供发证机构去签名了。一般来说，发证机构需要首先验证申请人的身份信息，然后对CSR提交的信息进行核对和签名，并将签名之后的证书发给申请者，或供其下载。下面以 FreeBSD、OpenSSL 为例介绍从生成公钥/私钥对到签发、安装证书的全过程。

在 Apache 文档中提到，不能在单个 IP 上同时有多个按名字识别的虚拟主机(“named virtual host”)。不完全是这样。

HTTPS协议的过程是：服务器首先与客户机之间进行服务器身份验证并协商安全会话，然后，客户端向服务器发送 HTTP 请求。这样一来，在客户端开始发送请求之前，服务器就已经把证书发给了客户端（客户端根据本地的根证书去验证证书链，等等）。而最重要的是，为了表明身份，这个证书的周知名称（“Common Name”）填写的应该是域名，否则浏览器会给出警告。

进版画面说：某银行专业版「证书链出错」，暂时不能登录，请耐心等待。不用打9***5了，很难打，而且他们也不懂，提供不了任何有用的信息。基金和银证转帐用电话凑合一下，查询、小额支付用大众版将就一下——9***5如是说。

防止下次再求助于archive。这是我用来给自己的SMTP/POP3/HTTPS服务器生成证书的全部命令行，仅限服务器证书部分。

cd /usr/local/CA
openssl req -nodes -new -x509 -keyout mykey.pem -out myreq.pem \
-days 365 -config openssl.cnf
openssl x509 -x509toreq -in myreq.pem -signkey mykey.pem -out tmp.pem
openssl ca -config openssl.cnf -policy policy_anything \
-out mycert.pem -infiles tmp.pem
rm -f tmp.pem

在招商银行发布"网上银行安全助手"引致问题不久，招商银行再次干出了一件令人瞠目结舌的事情—-他们发布的安装文件，竟然没有做数字签名。

一家金融机构制作的，具有如此重要意义的文件，居然不做数字签名？更可气的是，致电95555投诉的时候，客服竟然很礼貌地告诉我，域名对就可以保证安全。

以下内容为作弊条，仅供参考；只保证在FreeBSD下能用。

为postfix配置TLS的关键是产生自己的CA证书，并签署一年一续的服务证书。注意一定要保管好前者的私钥！

第一步，创建自签名CA：

mkdir /usr/local/etc/ca
cd /usr/local/etc/ca
mkdir certs crl newcerts private
echo 「01」 > serial
cp /dev/null index.txt
cp /etc/ssl/openssl.cnf openssl.cnf
vi openssl.cnf

想着想着还是给忘了，忘记了更新证书，以至于看到「根据您系统的当前时间，服务器提供的证书已过期」发愣了一阵。

也许应该写一个自动提醒程序？