usual2970

Certimate 使用 DNS-01 质询验证你的域名的所有权，截至本文发布时已支持 20+ 域名托管商。但是仍有用户持有的域名不在支持的范围内，或者想给客户申请证书但是域名不在自己的掌控范围内。

对于这些情况，我们通常可以：

1. 将域名转到到支持的托管商。
2. 使用 HttpRequest 自定义校验方法。
3. 使用 CNAME 方式，给托管商不在支持范围的域名添加 CNAME 到在支持范围内的域名。

本文主要讨论 CNAME 方式。

操作步骤​

假设你有:

1. a.com 托管商不在支持范围内。
2. b.com 托管商在支持范围内。
3. 你想给 www.a.com 申请证书。

1. 给 a.com 添加 CNAME 记录​

登录 a.com 所在托管商的后台，添加 CNAME 解析：

_acme-challenge.www.a.com  CNAME  www.a.com.validationserver.b.com

2. 在 Certimate 上配置工作流​

在 Certimate 上配置工作流，域名填写 www.a.com，DNS 提供商授权选择 b.com 所在的提供商的授权。

3. 执行工作流​

保存后执行即可。

原理​

Certimate 底层使用 Lego，通过将 _acme-challenge.你的域名 设置为指向你控制的验证域名的 CNAME，Lego 可以在该验证域名上自动创建 TXT 记录，从而完成 ACME 服务器的验证。

这种方式避免了直接修改主域名的 DNS 记录，使证书申请更加灵活，适用于托管服务或自动化证书管理场景。

参考​

Onboarding Your Customers with Let's Encrypt and ACME

Certimate 越来越受欢迎，需求也越来越多，这就要求我们根据需求完善、扩展 Certimate 的功能。在扩展 Certimate 的过程中，我们发现传统表单的表达能力实在有限，有些需求很难基于现有的表单来扩展。所以在 v0.3.0 版本中，我们主要引入了工作流的概念。

Certimate 作为作者工作中提升工作效率的工具，很好的符合了我个人的工作场景。但是在开源后，遇到了五花八门的需求，这些需求对应的场景有些是我不曾考虑到的。

这就导致在满足各种需求的同时，很难做到完全向后兼容，所以就出现了第一个不向后兼容的版本：v0.2.0。

我在平时的工作过程中要管理多个站点，这些站点基本都部署在各种 CDN 上，在国内，所有厂商的服务都不会自动给你的域名添加证书，这就需要我定期的去操作，非常麻烦的同时也容易忘掉，这就是我为什么要写 Certimate 的原因。

Certimate 开源后，我收到了很多用户的反馈。其中有一些诸如：为什么不用 Caddy 呢？除了有 UI 外它和 acme.sh 有什么区别呢？这里写一篇文章来解释一下。