什么是 EST（Enrollment Over Secure Transport，安全传输注册）协议？

EST 以易用性和安全特性著称，包括采用HTTPS 实现安全传输和传输层安全（TLS）保障客户端与服务端的安全。它还支持椭圆曲线密码学（ECC）、椭圆曲线数字签名算法（ECDSA）等更多加密算法，这一点有别于其他广泛使用的证书管理协议，比如由思科主导、在 20 世纪 90 年代开发的简单证书注册协议（SCEP）。因此，互联网工程任务组（IETF）工作组已提出将 EST 作为 SCEP 的替代方案。

为什么使用安全传输注册协议？

尽管公钥基础设施（PKI）提供的数字身份是目前安全性最强、最易用的身份认证与加密解决方案，但手动管理 PKI 证书本身存在诸多潜在隐患。企业需要 EST 这类证书管理自动化标准，来确保证书在无需人工干预的情况下完成大规模正确配置与部署。

事务繁忙的 IT 团队难以承担手动部署和管理证书的成本，这种方式风险高、耗时长且极易出错。无论是企业仅为网页服务器部署单张 SSL 证书，还是需要管理组织内所有联网终端、移动设备、用户身份对应的数百万张证书，单张证书从签发、配置到部署的流程就可能耗费数小时。

此外，手动管理证书会让企业面临极高风险还会导致证书易被遗忘直至过期，进而造成关键业务系统突然业务中断，使企业面临恶意攻击风险。

EST 实现的自动化水平不仅有助于降低风险，还能帮助 IT 管理员在繁忙的日常工作中节省宝贵时间。

证书注册场景下的EST与SCEP对比

与EST类似，SCEP也是一种帮助IT管理员自动签发证书的证书管理协议，作为企业安全的重要组成部分，SCEP已在企业中获得广泛应用。EST和SCEP都是适用于自动化证书注册的协议，且注册流程相近。

但IETF工作组已将EST确立为SCEP的替代方案。作为一种更新的协议，EST提供了易用的证书管理解决方案和更新的功能，为当今的企业公钥基础设施（PKI）环境带来多项核心优势，包括：

• 安全传输：其天生具备安全性：所有客户端与服务器之间的请求和响应都通过TLS传输，无需像SCEP那样使用共享密钥标识对消息编码以完成认证，也无需像自动化证书管理环境协议（ACME）那样通过质询密码完成消息认证。
• 指定证书请求方：在EST协议下，证书签名请求（CSR）可与经TLS认证的特定可信请求方绑定。而使用SCEP时，CSR需通过客户端与证书颁发机构（CA）之间的共享密钥完成认证，一旦共享密钥丢失或泄露，就会引入安全风险。
• 密码敏捷性与算法支持：EST支持ECC和ECDSA算法，而SCEP不支持——因为SCEP用于数据保护的PKCS 7方法仅依赖RSA加密算法。此外，这种算法独立性使EST具备一定的密码敏捷性，可原生支持未来的密码算法。
• 自动化证书续期：EST的设计原生支持自动重新注册。尽管近期提交的SCEP更新草案引入了续期消息，但此前SCEP并不支持重新注册。因此，许多已有的SCEP实现需要IT团队对其管理系统进行大幅改造，才能支持自动化证书续期。
• 服务端密钥生成：对于资源公钥基础设施（RPKI）环境，或是无法生成随机私钥的资源受限设备，服务端密钥生成是必需功能。SCEP仅支持客户端生成私钥，而EST允许由服务器生成私钥。
• 支持信任根增量更替的过渡期：在证书颁发机构（CA）更替或需要变更信任根的场景下，EST采用证书管理协议（CMP）的CA证书更替模型，但并未使用CMP的消息语法或协议。EST提供的模型可在过渡期内通过三张证书完成信任根更新，过渡期支持所有证书逐步完成向新根CA的更替，同时维持客户端与EST服务器之间的通信。反观SCEP，要求所有证书必须在指定日期一次性完成CA更替，若更替过程出现问题，可能导致关键业务系统面临服务中断风险。
• 证书吊销：EST没有用于获取证书吊销状态的机制。但这一问题影响不大，因为其缺少证书吊销列表（CRL）获取功能并不构成使用障碍——在线证书状态协议（OCSP）和OCSP装订提供了完整的吊销状态查询能力，应当使用这些技术实现该功能。SCEP确实提供了CRL获取消息，允许端点获取特定证书的吊销状态，但该功能价值有限：近期Firefox已弃用CRL，转而使用OCSP。

EST协议的工作原理是什么？

EST注册服务对客户端与证书颁发机构（CA）之间证书签发所需的互操作性和安全信息交换进行了标准化，可广泛应用于多种证书注册场景，包括Web服务器、DevOps、端点设备、IoT设备、用户身份、电子邮件服务，以及其他所有使用公钥基础设施（PKI）证书的场景。

在公钥基础设施（PKI）架构中，EST服务部署于客户端与证书颁发机构（CA）之间，承担传统上分配给注册机构（RA）角色的多项职能，负责验证EST客户端是否应当获得其申请的证书。若验证通过，EST服务会将请求转发给CA，再将签发完成的证书返回给客户端。客户端与EST服务器通信，EST服务器通过标准URL路径监听请求，客户端仅需知道服务器的IP地址即可发起请求。

EST注册流程的设计目标是简化从可信证书颁发机构（CA）自动化签发证书的部署，常规的客户端/服务器交互流程如下：

1. 客户端与EST服务器建立TLS加密的HTTP会话，并验证服务器提供的证书。
2. 客户端向服务器请求并验证信任链，包括根CA与EST CA之间的所有中间证书，同时存储根证书。
3. 客户端生成密钥和CSR，随后构造PKCS#10证书请求并发送给服务器。
4. EST 服务器向证书颁发机构（CA）请求并接收其签发的证书，随后将签名后的证书以 PKCS#7 格式返回给客户端，以便存储在客户端设备上。

此外，EST 客户端可通过向 EST 服务器提交重新注册请求，完成现有客户端证书的续期或密钥更新。EST 还可传输其他可选请求以支持更多证书操作，例如传递证书颁发机构（CA）可能需要的 CSR 属性，以及支持服务端密钥对生成。

客户端可调用的标准化请求功能及其对应 URI 路径包括：

• CA 证书分发（/cacerts）
• 客户端注册（/simpleenroll）
• 客户端重新注册（/simplereenroll）
• 基于 CMS (CMC) 的全量证书管理（/fullcmc）
• 服务端密钥生成（/serverkeygen）
• CSR 属性（/csrattrs）

Sectigo 支持

Sectigo 充分认知企业证书需求的复杂性与规模。企业依赖公钥基础设施（PKI）证书完成各类对象的身份认证与加密，覆盖云端与本地的 Web 服务器、联网设备、移动设备、用户身份、邮件系统、网络设备、IoT 设备、DevOps 环境、数字签名等诸多场景。Sectigo 提供支持 EST 的 SSL、代码签名、S/MIME 及其他 X.509 证书，同时提供自动化端到端证书生命周期管理（CLM）系统，支持企业通过统一视图实现证书的规模化管理。

配置 Sectigo EST 服务操作简便，可按照以下步骤执行：

1. 作为前置条件，Sectigo 会为您部署一个 EST 实例，并提供 EST 配置应用的 URL 及身份认证凭据。
2. 您可通过浏览器登录配置应用，启动配置流程。
3. 创建一个或多个适配器，将 EST 服务与 Sectigo 证书签发系统对接。
4. 随后创建一个或多个模板，将传入请求映射至对应的适配器，由此控制哪些客户端可以申请特定类型的证书。

完成上述步骤后，您即可通过 Sectigo EST 服务测试并执行证书注册或重新注册操作。

有关使用 Sectigo Certificate Manager 配置 EST 的完整指南（包括适配器与模板的创建方法），请访问 Sectigo 知识库并参考《Sectigo Certificate Manager 管理指南》。

有关配置文件中需指定的参数取值详情，请联系您的400-002-9968