5.2. 创建证书签名请求


传统上,以下方法用于生成证书请求(CSR):

  • 使用命令行工具生成 CSR
  • 在支持浏览器中生成 CSR
  • 在应用程序内生成 CSR,如服务器的安装程序

其中一些方法支持直接提交 CSR,而有些方法则不支持。

从 Red Hat Certificate System 9.7 开始,支持服务器-Side 密钥生成,克服了在较新版本的浏览器(如 Firefox v69 和 up)内生成密钥的支持,如 Firefox v69 和 up 以及 Chrome。因此,在本节中,我们将不讨论对密钥生成的浏览器支持。

从应用程序生成的 CSR 通常采用 PKCS11410 的形式。如果它们被正确生成,则 RHCS 应该支持它们。

以下小节介绍了 Red Hat Certificate System 支持的以下方法:

  • 命令行工具
  • 服务器端密钥生成

5.2.1. 使用命令行工具生成 CSR

Red Hat Certificate System 支持使用以下工具来创建 CSR:

  • certutil :支持创建 PKCS #10 请求。
  • PKCS10Client :支持创建 PKCS #10 请求。
  • CRMFPopClient :支持创建 CRMF 请求。
  • pki client-cert-request :支持 PKCS#10 和 CRMF 请求。

以下小节提供了如何将这些工具与功能丰富的注册配置集框架搭配使用的一些示例。

5.2.1.1. 使用 certutil创建 CSR

这部分论述了如何使用 certutil 工具创建 CSR 的示例。

有关使用 certutil 的详情,请参考:

  • certutil (1) man page
  • certutil --help 命令的输出
5.2.1.1.1. 使用 certutil 创建带有 EC 密钥的 CSR

以下流程演示了如何使用 certutil 工具创建 Elliptic Curve (EC)密钥对和 CSR:

  1. 切换到正在请求证书的用户或实体的证书数据库目录,例如:

    $ cd /user_or_entity_database_directory/
  2. 创建二进制 CSR,并将其存储在 /user_or_entity_database_directory/request.csr 文件中:

    $ certutil -d . -R -k ec -q nistp256 -s "CN=subject_name" -o /user_or_entity_database_directory/request-bin.csr

    提示时输入所需的 NSS 数据库密码。

    有关参数的详情,请查看 certutil (1) 手册页。

  3. 将创建的二进制格式 CSR 转换为 PEM 格式:

    $ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr
  4. (可选)验证 CSR 文件是否正确:

    $ cat /user_or_entity_database_directory/request.csr
    
    		MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs
    		...

    这是一个 PKCS the10 PEM 证书请求。

  5. 有关后续步骤,请参阅 第 5.5.2 节 “CMC 注册过程”,但跳过创建证书请求的步骤。
5.2.1.1.2. 使用 certutil 创建带有用户定义的扩展的 CSR

以下流程演示了如何使用 certutil 工具创建带有用户定义的扩展的 CSR。

请注意,注册请求受 CA 定义的注册配置集的限制。请参阅 例 B.3 “CSR 中提供了多个用户扩展”

  1. 切换到正在请求证书的用户或实体的证书数据库目录,例如:

    $ cd /user_or_entity_database_directory/
  2. 使用用户定义的 Key Usage 扩展以及用户定义的扩展密钥用法扩展创建 CSR,并将其存储在 /user_or_entity_database_directory/request.csr 文件中:

    $ certutil -d . -R -k rsa -g 1024 -s "CN=subject_name" --keyUsage keyEncipherment,dataEncipherment,critical --extKeyUsage timeStamp,msTrustListSign,critical -a -o /user_or_entity_database_directory/request.csr

    提示时输入所需的 NSS 数据库密码。

    有关参数的详情,请查看 certutil (1) 手册页。

  3. (可选)验证 CSR 文件是否正确:

    $ cat /user_or_entity_database_directory/request.csr
    		Certificate request generated by Netscape certutil
    		Phone: (not specified)
    
    		Common Name: user 4-2-1-2
    		Email: (not specified)
    		Organization: (not specified)
    		State: (not specified)
    		Country: (not specified)

    这是一个 PKCS the10 PEM 证书请求。

有关后续步骤,请参阅 第 5.5.2 节 “CMC 注册过程”,但跳过创建证书请求的步骤。

注意

从 CSR 中删除标头信息。

5.2.1.2. 使用 PKCS10Client创建 CSR

本节论述了如何使用 PKCS10Client 工具创建 CSR。

有关使用 PKCS10Client 的详情,请参考:

  • PKCS10Client (1) 手册页
  • PKCS10Client --help 命令的输出
5.2.1.2.1. 使用 PKCS10Client 创建 CSR

以下流程解释了如何使用 PKCS10Client 工具创建 Elliptic Curve (EC)密钥对和 CSR:

  1. 切换到正在请求证书的用户或实体的证书数据库目录,例如:

    $ cd /user_or_entity_database_directory/
  2. 创建 CSR 并将其存储在 /user_or_entity_database_directory/example.csr 文件中:

    $ PKCS10Client -d . -p NSS_password -a ec -c nistp256 -o /user_or_entity_database_directory/example.csr -n "CN=subject_name"

    有关参数的详情,请查看 PKCS10Client (1) 手册页。

  3. (可选)验证 CSR 是否正确:

    $ cat /user_or_entity_database_directory/example.csr
    		-----BEGIN CERTIFICATE REQUEST-----
    		MIICzzCCAbcCAQAwgYkx
    		...
    		-----END CERTIFICATE REQUEST-----
5.2.1.2.2. 使用 PKCS10Client 为基于 SharedSecret 的 CMC 创建 CSR

以下流程解释了如何使用 PKCS10Client 工具为基于 SharedSecret 的 CMC 创建 RSA 密钥对和 CSR。只使用它与 CMC Shared Secret 身份验证方法一起使用,它默认由 caFullCMCSharedTokenCertcaECFullCMCSharedTokenCert 配置集处理。

  1. 切换到正在请求证书的用户或实体的证书数据库目录,例如:

    $ cd /user_or_entity_database_directory/
  2. 创建 CSR 并将其存储在 /user_or_entity_database_directory/example.csr 文件中:

    $ PKCS10Client -d . -p NSS_password -o /user_or_entity_database_directory/example.csr -y true -n "CN=subject_name"

    有关参数的详情,请查看 PKCS10Client (1) 手册页。

  3. (可选)验证 CSR 是否正确:

    $ cat /user_or_entity_database_directory/example.csr
    		-----BEGIN CERTIFICATE REQUEST-----
    		MIICzzCCAbcCAQAwgYkx
    		...
    		-----END CERTIFICATE REQUEST-----

5.2.1.3. 使用 CRMFPopClient创建 CSR

证书请求消息格式(CRMF)是 CMC 中可接受的 CSR 格式,它允许在请求中安全地嵌入密钥归档信息。

这部分论述了如何使用 CRMFPopClient 工具创建 CSR。

有关使用 CRMFPopClient 的详情,请查看 CRMFPopClient (1) 手册页。

5.2.1.3.1. 使用 CRMFPopClient 创建带有密钥 Archival 的 CSR

以下流程解释了如何使用 CRMFPopClient 工具创建带有密钥 archival 选项的 RSA 密钥对和 CSR:

  1. 切换到正在请求证书的用户或实体的证书数据库目录,例如:

    $ cd /user_or_entity_database_directory/
  2. 检索 KRA 传输证书:

    $ pki ca-cert-find --name "DRM Transport Certificate"
    		---------------
    		1 entries found
    		---------------
    			Serial Number: 0x7
    			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
    			Status: VALID
    			Type: X.509 version 3
    			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
    			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
    			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
    			Issued On: Thu Oct 22 18:26:11 CEST 2015
    			Issued By: caadmin
    		----------------------------
    		Number of entries returned 1
  3. 导出 KRA 传输证书:

    $ pki ca-cert-show 0x7 --output kra.transport
  4. 创建 CSR 并将其存储在 /user_or_entity_database_directory/example.csr 文件中:

    $ CRMFPopClient -d /home/example-user/certs_db -p password -n "CN=user_name" -q POP_SUCCESS -b kra.transport -w "AES KeyWrap/Wrapped" -v -o ~/user_name.req -oaep

    要创建 Elliptic Curve (EC)密钥对和 CSR,请将 -a ec -t false 选项传给命令。

    有关参数的详情,请查看 CRMFPopClient (1) 手册页。

    注意

    如果为其配置了服务器,则 use -oaep。如果现代 HSM 首选 AES/CBC/PKCS5Padding,则使用 AES KeyWrap/WrapWrapped。

  5. (可选)验证 CSR 是否正确:

    $ cat /user_or_entity_database_directory/example.csr
    		-----BEGIN CERTIFICATE REQUEST-----
    		MIICzzCCAbcCAQAwgYkx
    		...
    		-----END CERTIFICATE REQUEST-----
5.2.1.3.2. 使用 CRMFPopClient 为基于 SharedSecret 的 CMC 创建 CSR

以下流程解释了如何使用 CRMFPopClient 工具为基于 SharedSecret 的 CMC 创建 RSA 密钥对和 CSR。只使用它与 CMC Shared Secret 身份验证方法一起使用,它默认由 caFullCMCSharedTokenCertcaECFullCMCSharedTokenCert 配置集处理。

  1. 切换到正在请求证书的用户或实体的证书数据库目录,例如:

    $ cd /user_or_entity_database_directory/
  2. 检索 KRA 传输证书:

    $ pki ca-cert-find --name "DRM Transport Certificate"
    		---------------
    		1 entries found
    		---------------
    			Serial Number: 0x7
    			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
    			Status: VALID
    			Type: X.509 version 3
    			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
    			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
    			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
    			Issued On: Thu Oct 22 18:26:11 CEST 2015
    			Issued By: caadmin
    		----------------------------
    		Number of entries returned 1
  3. 导出 KRA 传输证书:

    $ pki ca-cert-show 0x7 --output kra.transport
  4. 创建 CSR 并将其存储在 /user_or_entity_database_directory/example.csr 文件中:

    $ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -y -v -o /user_or_entity_database_directory/example.csr

    要创建 EC 密钥对和 CSR,请将 -a ec -t false 选项传给命令。

    有关参数的详情,请查看 CRMFPopClient --help 命令的输出。

  5. (可选)验证 CSR 是否正确:

    $ cat /user_or_entity_database_directory/example.csr
    		-----BEGIN CERTIFICATE REQUEST-----
    		MIICzzCCAbcCAQAwgYkx
    		...
    		-----END CERTIFICATE REQUEST-----

5.2.1.4. 在 PKI CLI 中使用 client-cert-request 创建 CSR

pki'command-line 工具也可以与 'client-cert-request 命令一起使用 来生成 CSR。但是,与前面讨论的工具不同,使用 pki 生成的 CSR 将直接提交到 CA。可以同时生成 PKCS11410 或 CRMF 请求。

  • 生成 PKCS the10 请求的示例:
pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type pkcs10
  • 生成 CRMF 请求的示例:
pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type crmf

成功后将返回请求 ID。

提交请求后,代理可以使用 pki ca-cert-request-approve 命令批准它。

例如:

pki -d agent token db directory -P https -p 8443 -h host.test.com -c agent token db passwd -n <CA agent cert nickname> ca-cert-request-approve request id

如需更多信息,请参阅 pki client-cert-request --help 命令 的 man page。

5.2.2. 使用 Server-Side Key Generation 生成 CSR

许多新版本的浏览器(包括 Firefox v69 和 Chrome)都删除了生成 PKI 密钥的功能,并支持密钥归档的 CRMF。在 RHEL 上,CRMFPopClient (请参阅 CRMFPopClient --help)或 pki (请参阅 pki client-cert-request --help)可用作临时解决方案。

由于引入令牌密钥管理系统(TMS),服务器端密钥注册时间已延长,其中密钥可以在 KRA 上生成,而不是本地在智能卡上生成。Red Hat Certificate System 现在采用类似的机制来解决浏览器 keygen ficiency 问题。密钥在服务器上生成(特别是,在 KRA 上),然后安全地将密钥传输给 PKCS the 中的客户端。

注意

强烈建议您仅将服务器端密钥机制用于加密密钥。

5.2.2.1. 功能亮点

  • 证书请求密钥在 KRA 上生成(注意:必须安装 KRA 才能使用 CA)
  • 配置文件默认插件 serverKeygenUserKeyDefaultImpl 提供对启用或禁用密钥归档(例如,enableArchival 参数)的选择
  • 支持 RSA 和 EC 密钥
  • 支持手动(代理)批准和自动批准(例如,基于密码的目录)

5.2.2.2. 使用 Server-Side keygen 注册证书

默认的 Server-Side Keygen 注册配置文件可在 EE 页面中找到,在 List Certificate Profiles 选项卡下:

使用 Server-Side 密钥生成手动用户双使用证书注册

图 5.1. 需要代理手动批准的服务器-Side Keygen Enrollment

服务器端 keygen 注册手册
使用 Server-Side 密钥生成目录验证的用户双使用证书注册

图 5.2. Server-Side keygen 注册,它会在成功 LDAP uid/pwd 身份验证后自动批准

服务器端 keygen ldap auth

无论请求是如何批准的,服务器端密钥注册机制都需要最终用户输入 PKCS the package 的密码,该软件包将包含发布的证书以及服务器生成的加密私钥。

重要

用户不应与任何人共享密码。甚至不是 CA 或 KRA 代理。

当注册请求被批准后,将生成 PKCS the 软件包,

  • 如果进行手动批准,PKKKKKM 文件将返回到批准请求的 CA 代理;然后代理应该将 PKCS the 文件转发到用户。
  • 如果进行自动批准,PKKKKKKT 将会返回到提交请求的用户

图 5.3. 代理手动批准的注册

服务器端 keygen 注册批准

收到 PKCSburst 文件后,用户可以使用 CLI (如 pkcs12util )将此文件导入到每个应用程序自己的用户内部证书/密钥数据库中。例如,用户的 Firefox nss 数据库。

5.2.2.3. 密钥恢复

如果在证书注册配置文件中将 enableArchival 参数设置为 true,则在 Server-Side Keygen 注册时会存档私钥。然后,授权的 KRA 代理可以恢复归档的私钥。

5.2.2.4. 其他信息

5.2.2.4.1. KRA 请求记录
注意

由于此机制的性质,如果配置集中的 enableArchival 参数设置为 true,则每个 Server-Side keygen 请求有两个 KRA 请求记录:

  • 一个请求类型 asymkeyGenRequest

    无法使用 KRA 代理页上的 List Requests 过滤此请求类型;您可以选择 Show All Requests 来查看列出它们。

  • 一个请求类型 恢复
5.2.2.4.2. 审计记录

如果启用了,可以观察一些审计记录:

CA
  • SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST
  • SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST
KRA
  • SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST_PROCESSED
  • SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST_PROCESSED (还没有实现)
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.