TLS证书签发分析

近期在使用1Panel面板签发 TLS 证书时出现一些未知问题，因此决定对 TLS 证书签发流程做详细分析和学习，以便分析签发失败的原因

本文将以1Panel + Acme协议（Let's Encrypt）展开论述，先记录常规签发流程，再进行签发流程分析。

1Panel TLS 证书签发流程

  1. 打开1Panel，前往【网站-证书】页面；
  2. 添加Acme账户： 点击按钮【Acme账户】，点击【创建】，在对话框中输入自己的邮箱、账号类型默认（Let's Encrypt）、密钥算法默认（EC 256），最后确认；
  3. 添加DNS账户： 点击按钮【DNS账户】，点击【创建】，在对话框中填入名称（随意）、选择类型（域名DNS服务商）、填写相关密钥；
  4. 签发证书： 点击按钮【申请证书】，对话框中填入主域名、其他域名（可选），选择Acme账户、DNS账户，点击确定，等待签发成功。

短短4步，TLS 证书就签发完毕了，接下来就可以把 TLS 证书绑定到自己的应用上了。

签发步骤分析

密钥算法

  • EC 256 (P-256 / prime256v1)
  • EC 384 (P-384 / secp384r1)
  • RSA 2048
  • RSA 3072
  • RSA 4096

后面的数字代表密钥长度（单位是：位 bit），这五种也是目前TLS证书中最常见的密钥算法，其中主要就分成两大类：EC和RSA。

EC：ECC (Elliptic Curve Cryptography，椭圆曲线加密)，现代加密的首选，通过更短的密钥实现更高的安全性。安全性基于椭圆曲线离散对数问题。其中 EC 256 是现代互联网的加密首选，而 EC 384 比 EC 256 更安全性、也更慢，但依旧比 RSA 快。

RSA：(Rivest–Shamir–Adleman)，最经典、兼容性最好的非对称加密算法。安全性基于大整数因子分解的数学难题。RSA 2048最经典、兼容性也最好，RSA 3072和RSA 4096，按照密钥长度增加，带来了更高的安全性，也极大的拖慢了运算时间。

总结：一般没特殊要求，选EC 256。

验证方式

  • DNS账号
  • 手动解析
  • HTTP

DNS账号

核心原理： 程序通过调用API操作DNS账号，直接添加一条特定的TXT记录来证明申请者的控制权。

签发流程：

  1. 向CA（证书签发平台）发起申请；
  2. CA生成一个随机字符串作为验证内容；
  3. 调用DNS服务商的API，添加一条TXT记录。记录名例如：_acme-challenge.example.com，记录值就是步骤（2）生成的随机字符串；
  4. 验证刚刚添加的DNS记录是否有效，CA也会验证；
  5. DNS记录有效，CA颁发证书；
  6. 自动删除TXT记录。

该方法支持泛域名证书申请，并且CA并不会验证该域名具体指向何处，只会验证TXT记录是否有效，因此并不需要申请的服务器有公网IP，还很适合自动化续签。缺点是API Key可能存在泄漏风险，DNS解析过程也可能会有一定延迟。

手动解析

跟 DNS账号 的原理差不多，也是用TXT记录证明申请者的控制权。只不过整个过程中，添加TXT DNS解析记录、触发CA验证DNS是否有效得手动进行。

HTTP

核心原理： 要求在网站的特定路径下放文件，CA通过HTTP协议访问并验证该文件。

签发流程：

  1. 用户向CA发起申请；
  2. CA提供两个文件供下载；
  3. 用户下载文件到网站特定的目录下；
  4. 用户触发验证；
  5. CA发起HTTP GET请求，访问地址，并检查域名是否解析正确、文件内容是否符合预期；
  6. 成功，则颁发证书。

相比之下，不用担心 DNA账号 的API Key泄漏，但手动操作也增加了复杂性，得有可访问的、正在运行的网站，而且无法生成泛域名证书。

TLS证书签发分析 - 特恩的日志