简单证书注册协议(SCEP)详解

发表于 2021/09/09 更新于 2021/09/10

作者 Jinkai 22 分钟阅读

本文将会介绍简单证书注册协议(Simple certificate enrollment protocol, SCEP)，并对整个证书签发流程做详细的分析

概述

SCEP(Simple certificate enrollment protocol)，简单证书注册协议，最初由 CISCO 起草，简而言之，就是一个用来注册数字证书的协议。

RFC 8894描述了简单的证书注册协议(SCEP)。该协议的旧版本成为实际工业标准，用于实际提供数字证书，主要用于网络设备。该协议旨在使任何标准网络用户的要求和颁发的数字证书尽可能简单。这些流程通常需要网络管理员的密集输入，因此不适合大规模部署。

简单的证书注册协议仍然是最受欢迎和广泛可用的证书注册协议，被许多网络设备和软件制造商使用，他们正在开发简化的处理证书的方法，以便向日常用户大规模实施。例如，思科 IOS 操作系统(即使思科正在推动功能稍多的 EST)和 iPhone 注册企业 PKI。大多数 PKI 软件(特别是 RA 实现)都支持它，包括活动目录证书服务的网络设备注册服务 (NDES)。

历史

SCEP 由 Verisign 为思科设计，作为 CMS (CMC)证书管理、以及功能强大但体积相当庞大的证书管理协议(CMP)的精益替代方案。2010 年左右，思科暂停了 SCEP 的工作，转而开发了 EST。2015 年， Peter Gutmann 恢复了互联网草案(Internet Draft)，原因是 SCEP 在工业和其他标准中广泛使用。他用更现代的算法更新了草稿，纠正了原始规范中的许多问题。2020 年 9 月，该草案作为RFC 8894发布，SCEP 从草案到标准花费了近 20 年。新版本还支持注册非 RSA 证书(例如ECC公钥)。

RA 简介

注册机构(Registration Authority, RA) 是公开密钥基础设施(Public Key Infrastructures, PKI)中使用的证书注册功能。它负责接收来自人员、服务器、事物或其他应用程序的证书签名请求(CSR)–初始注册或续订。注册机构验证这些请求并转发给证书颁发机构 (Certificate Authority, CA)。

注册机构还负责接收其他证书生命周期管理职能。例如，撤销。RA 实施接受请求的业务逻辑，需要能够验证请求方和应具有证书的一方的来源。

出于无障碍和安全原因，注册机构通常与证书颁发机构分开。通过用户友好型 GUI 或集成友好型 API 和标准协议访问 RA。

在Cisco Systems’ Simple Certificate Enrollment Protocol draft-nourse-scep-22这篇文章中讲述了客户端如何通过 SCEP 协议访问 RA 接口，由于 SCEP 协议当时还处于草案阶段，所以该文章只能作为参考。SCEP 的正式标准是RFC 8894。但是由于草案的大规模使用，本文还是会以草案作为基础对 SCEP 协议做介绍

SCEP 实体

SCEP 中定义的实体类型：

请求者(Requester)
例如，IPSec 客户端
服务器(Server)
证书颁发机构 (Certificate Authority, CA)或注册机构(Registration Authority, RA)

SCEP 的特点

基于HTTP的请求/响应模式(使用 GET 方法，POST 也可以支持)
只支持RSA加密(目前国际通用、使用广泛的公钥算法也就 RSA, ECC，而 ECC 是没有公钥加密，私钥解密标准的，我猜这个特点有这个原因吧)
证书请求用PKCS #10标准(也就是 CSR 格式的一种标准)
采用PKCS #7标准传输签名/加密数据(HTTP 请求非常不安全，容易被拦截，篡改)
支持服务器异步授权，客户端定期轮询
具有有限的证书吊销列表(CRL)检索支持(首选方法是通过 CRL 分发点(CDP)查询，出于可伸缩性原因)
不支持在线证书吊销(必须通过其它方法执行脱机)
需要在证书签名请求(CSR)中使用质询密码(Challenge Password)字段，该字段必须仅在服务器和请求者之间共享

证书注册过程简述

取得 CA 证书的副本，并对其进行验证
生成一个 CSR(Certificate Signing Reques)，并把它安全地传输到 CA
轮询 SCEP 服务器，检查证书是不是已经被签名了
根据需要重新注册，以便在当前证书到期之前获得新证书。
根据需要检索 CRL。

证书注册流程

CA 认证:获取 CA 证书

SCEP 使用 CA 证书来加密 CSR 的消息交换。因此，必须获得 CA 证书的副本。使用 GetCACert 操作。

请求

请求被发送作为 HTTP GET 请求。请求的信息包获取看起来类似于此：

GET /cgi-bin/pkiclient.exe?operation=GetCACert

响应

响应只是二进制编码的 CA 证书 (X.509)。客户端需要验证 CA 证书通过指纹/哈希的检查。这必须通过带外(out-of-band)方法(呼叫系统管理员或信任点内指纹的预配置)完成。

客户注册

请求

注册请求作为 HTTP GET 请求发送。请求的包捕获看起来与此类似：

/cgi-bin/pkiclient.exe?operation=PKIOperation&message= MIIHCgYJKoZIhvcNAQcCoIIG%2BzCCBvcCAQExDjA……

“message=”之后的文本是从 GET 请求字符串中提取的 URL 编码字符串。
然后，文本被 URL 解码为 ASCII 文本字符串。该文本字符串是 base64 编码的签名数据(SignedData) PKCS#7。
签名数据(SignedData) PKCS#7 由客户端使用以下证书中的一种签署;它被用来证明客户发送它，且没有在传输过程中被篡改：
- 自签证书(首次注册时使用)
- 制造商安装证书 (MIC)
- 即将到期的当前证书(重新注册)
签名数据(SignedData) PKCS#7 的”签名数据”部分是信封数据(EnvelopedData) PKCS#7。
信封数据(EnvelopedData) PKCS#7 是一个包含”加密数据”和”解密密钥”的容器。解密密钥使用收件人的公钥加密。在此特定情况下，收件人是 CA：因此。只有 CA 才能实际解密“加密数据”。
信封数据(EnvelopedData) PKCS#7 的”加密数据(Encrypted Data)”部分是 CSR (PKCS#10)。

响应

对 SCEP 注册请求的响应是三种类型之一：

Reject 拒绝 - 管理员以任何原因拒绝请求，例如：
- 无效密钥长度
- 无效质询密码(Challenge Password)
- CA 无法验证请求
- 请求要求 CA 提供未授权的属性
- 请求由 CA 不信任的身份签署
Pending 待定 - CA 管理员尚未审核该请求。
Success 成功 - 接受请求并包含签名证书。签名证书在称为”仅限退化证书-仅限 PCCS#7(Degenerate Certificates-Only PKCS#7)”的特殊类型的 PKCS #7 中保存，这是一种特殊容器，可容纳一个或多个 X.509 或 CRL，但不包含已签名或加密的数据有效载荷。

客户重新注册

在证书到期之前，客户需要获得新的证书。续订(renewal)和展期(rollover)之间有轻微的行为差异。当客户 ID 证书接近到期时，其到期日期与 CA 证书的到期日期不同(早于 CA 证书到期时间)时，就会发生续订。当 ID 证书接近到期，且时其到期日期与 CA 证书到期日期相同，就会发生展期。

续订

随着 ID 证书到期日期的临近，SCEP 客户可能想要获得新证书。客户端生成 CSR，并完成注册过程(如以前定义的)。当前证书用于签署签名数据 PKCS#7，这反过来又向 CA 证明身份。重新获得新证书后，客户立即删除当前证书，代之以新证书，新证书的有效期立即开始。

展期

展期是 CA 证书过期并生成新 CA 证书的特殊情况。CA 生成新的 CA 证书，一旦当前 CA 证书过期，该证书将生效。CA 通常会在展期前一段时间生成此”阴影 CA”证书，因为需要该证书才能为客户生成”阴影 ID”证书。

当 SCEP 客户 ID 证书即将到期时，SCEP 客户端会向 CA 查询”影子 CA”证书。此操作与 GetNextCACert 操作一起完成，如下图所示：

GET /cgi-bin/pkiclient.exe?operation=GetNextCACert

一旦 SCEP 客户拥有”影子 CA”证书，它会在正常注册程序后申请”影子 ID”证书。CA 在”阴影 ID”证书上签名，并标有”阴影 CA”证书。与正常的续订请求不同，退回的”阴影 ID”证书在 CA 证书到期(展期)时生效。因此，客户需要保留 CA 和 ID 证书的预展和后展期证书副本。在 CA 到期(展期)时，SCEP 客户端删除当前的 CA 证书和 ID 证书，并将其替换为”阴影”副本。

附录

PKCS#7

PKCS#7 is a defined data format that allows data to be signed or encrypted. The data format includes the original data and the associated metadata necessary in order to perform the cryptographic operation.

PKCS#7 是一种定义的数据格式，允许签名或加密数据。数据格式包括执行加密操作所需的原始数据和相关元数据。

Signed Envelope (SignedData)

The signed envelope is a format that carries data and confirms that the encapsulated data is not altered in transit via digital signatures. It includes this information:

签名信封是一种携带数据并确认封装数据在传输中不会通过数字签名更改的格式。它包括此信息：

SignedData &colon;:= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

Version number - With SCEP, version 1 used.版本编号 - 使用 SCEP 版本 1。
List of Digest Algorithms Used - With SCEP, there is only one Signer and thus only one Hashing Algorithm.使用的文摘算法列表 - 使用 SCEP，只有一个签名者，因此只有一个哈希算法。
Actual data that is signed - With SCEP, this is a PKCS#7 Enveloped-data format (Encrypted Envelope).已签名的实际数据 - 与 SCEP 一起，这是一个 PKCS#7 信封数据格式(加密信封)。
List of certificates of the signers - With SCEP, this is a self-signed certificate on initial enrollment or the current certificate if you re-enroll.签名者证书列表 - 通过 SCEP，如果您重新注册，这是初始注册时的自签名证书或当前证书。
List of the signers and the fingerprint generated by each signer - With SCEP, there is only one signer.签名者名单和每个签名者生成的指纹 - 有了 SCEP，只有一个签名者。

The data encapsulated is not encrypted or obfuscated. This format simply provides protection against the message that is altered.

封装的数据不加密或混淆。此格式仅提供完整性保护，防止消息被篡改。

Enveloped Data (EnvelopedData)

The Enveloped Data format carries data that is encrypted and can only be decrypted by the specified recipient(s). It includes this information:

信封数据格式携带的数据是加密的，只能由指定的收件人解密。它包括此信息：

EnvelopedData &colon;:= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

Version number - With SCEP, version 0 is used.版本编号 - 使用 SCEP 版本 0。
List of each of the recipients and the related encrypted data-encryption key - With SCEP, there is only one recipient (for requests: the CA server; for responses: the client).每个收件人的列表和相关的加密数据加密密钥 - 使用 SCEP，只有一个收件人(用于请求：CA 服务器; 用于响应：客户端)。
The encrypted data - This is encrypted with a randomly generated key (that has been encrypted with the recipient’s public key).加密数据 - 这是用随机生成的密钥(已与收件人的公钥加密)加密的。

PKCS#10

PKCS#10 describes the format of a CSR. A CSR contains the information that clients request be included within their certificates:

PKCS#10 描述了 CSR 的格式。CSR 包含客户请求包含在其证书中的信息：

Subject Name 主题名称
A copy of the public key 公共密钥副本
A challenge password (optional)质询密码(可选)
Any certificate extensions reqested, such as:任何已重新访问的证书扩展，例如：
- Key Usage (KU)密钥用途 (KU)
- Extended Key Usage (EKU)扩展密钥使用 (EKU)
- Subject Alternative Name (SAN)主题替代名称 (SAN)
- Universal Principal Name (UPN)通用主名称 (UPN)
A fingerprint of the request 请求的指纹

Here is an example of a CSR:

Certificate Request:
    Data&colon;
        Version: 0 (0x0)
        Subject: CN=scepclient
        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption                Public-Key: (1024 bit)
                Modulus:
                    00:cd:46:5b:e2:13:f9:bf:14:11:25:6d:ff:2f:43:
                    64:75:89:77:f6:8a:98:46:97:13:ca:50:83:bb:10:
                    cf:73:a4:bc:c1:b0:4b:5c:8b:58:25:38:d1:19:00:
                    a2:35:73:ef:9e:30:72:27:02:b1:64:41:f8:f6:94:
                    7b:90:c4:04:28:a1:02:c2:20:a2:14:da:b6:42:6f:
                    e6:cb:bb:33:c4:a3:64:de:4b:3a:7d:4c:a0:d4:e1:
                    b8:d8:71:cc:c7:59:89:88:43:24:f1:a4:56:66:3f:
                    10:25:41:69:af:e0:e2:b8:c8:a4:22:89:55:e1:cb:
                    00:95:31:3f:af:51:3f:53:ad
                Exponent: 65537 (0x10001)
        Attributes:
            challengePassword        :
        Requested Extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:webserver.example.com
    Signature Algorithm: sha1WithRSAEncryption
         8c:d6:4c:52:4e:c0:d0:28:ca:cf:dc:c1:67:93:aa:4a:93:d0:
         d1:92:d9:66:d0:99:f5:ad:b4:79:a5:da:2d:6a:f0:39:63:8f:
         e4:02:b9:bb:39:9d:a0:7a:6e:77:bf:d2:49:22:08:e2:dc:67:
         ea:59:45:8f:77:45:60:62:67:64:1d:fe:c7:d6:a0:c3:06:85:
         e8:f8:11:54:c5:94:9e:fd:42:69:be:e6:73:40:dc:11:a5:9a:
         f5:18:a0:47:33:65:22:d3:45:9f:f0:fd:1d:f4:6f:38:75:c7:
         a6:8b:3a:33:07:09:12:f3:f1:af:ba:b7:cf:a6:af:67:cf:47:         60:fc

SCEP 请求

请求消息格式

请求以 HTTP GET 表格形式发送：

GET CGI-path/pkiclient.exe?operation=operation&message=message HTTP/version

分析

CGI-path - 依赖于服务器，并指向处理 SCEP 请求的共同网关接口 (CGI) 程序：
- 思科 IOS® CA 使用空路径字符串。
- 微软 CA 使用/certsrv/mscep/mscep.dll，它指向 MSCEP/网络设备注册服务 (NDES) IIS 服务。
operation - 识别执行的操作。
message - 携带该操作的其他数据(如果不需要实际数据，则可以为空)。

使用 GET 方法，message部分可以是纯文本，或是由区分编码规则 (DER) 编码的 PKCS#7 转换的 Base64 格式数据。如果支持 POST方法，则可能以二进制格式取代的 GET 发送的 Base64 编码的内容。

请求结构说明

operation及其相关消息值的可能值：

operation = PKIOperation时:
- message是一个 SCEP pkiMessage结构，基于 PKCS#7，并编码为 DER 和 Base64。
- pkiMessage结构可以是这些类型的：
  - PCCSReq：PCKCS#10 CSR
  - GetCertInitial：CSR 签署状态的轮询
  - GetCert or GetCRL：证书或 CRL 检索
operation = GetCACert, GetNextCACert, or (optional)GetCACaps时
- message可以被省略，也可以被设置为标识 CA 的名称。

SCEP 响应

响应消息格式

SCEP 响应将作为标准 HTTP 内容返回，Content-Type 取决于原始请求和返回的数据类型。DER 内容以二进制内容返回(不使用和请求一样的 Base64)。PKCS#7 内容可能包含或可能不包含加密/签名的信封数据(enveloped data);如果不包含(只包含一组证书)，它被称为退化的 PKCS#7。

Content-Type

Content-Type 可能值：

application/x-pki-message:
- 响应 PKIOperation 操作，这些请求附带 pkiMessage 类型：PKCSReq、GetCertInitial、GetCert 或 GetCRL
- 响应主体是 pkiMessage 类型：CertRep
application/x-x509-ca-cert:
- 响应 GetCACert 操作
- 响应主体是 DER 编码的 X.509 CA 证书
application/x-x509-ca-ra-cert:
- 响应 GetCACert 操作
- 响应主体是包含 CA 和 RA 证书的 DER 编码的退化 PKCS#7
application/x-x509-next-ca-cert:
- 响应 GetNextCACert 操作
- 响应主体是 pkiMessage 类型的变体： CertRep

pkiMessage 结构

SCEP OIDs

16.840.1.113733.1.9.2 scep-messageType
16.840.1.113733.1.9.3 scep-pkiStatus
16.840.1.113733.1.9.4 scep-failInfo
16.840.1.113733.1.9.5 scep-senderNonce
16.840.1.113733.1.9.6 scep-recipientNonce
16.840.1.113733.1.9.7 scep-transId
16.840.1.113733.1.9.8 scep-extensionReq

SCEP pkiMessage

PKCS#7 签名数据(SignedData)
PKCS#7 信封数据(EnvelopedData)(称为 pkcsPKIEnvelope;可选，加密到消息接收者)
- messageData(CSR，证书， CRL，…)
具有经过验证的属性的签名信息(SignerInfo with authenticatedAttributes)：
- transactionID, messageType, senderNonce
- pkiStatus, recipientNonce (response only)
- failInfo (response + failure only)

SCEP messageType

请求：
- PCCSReq (19)： PCKCS#10 CSR
- GetCertInitial(20)：证书签署状态轮询
- GetCert(21)：证书检索
- GetCRL (22)： CRL 检索
响应：
- CertRep(3)：对证书或 CRL 请求的响应

SCEP pkiStatus

SUCCESS (0)：授予请求 (pkcsPKIEnvelope 中的响应)
FAILURE(2)：请求被拒绝 (失败信息属性中的详细信息)
PENDING (3)：请求等待人工批准

参考

技术

本文由作者按照 CC BY 4.0 进行授权