13.8. EE 的 ServerSide Key Generation

13.8.1. 概述

许多较新版本的浏览器（包括 Firefox v69 和 up）以及 Chrome 删除了生成 PKI 密钥以及对 key archival 的 CRMF 的支持的功能。虽然 CRMFPopClient 等 CLI （请参阅"CRMFPopClient --help"）或 pki （请参阅"pki client-cert-request --help"）可以用作 Fedora 或 RHEL 平台的临时解决方案，其他平台上的客户端已离职。

从引入令牌密钥管理系统(TMS)起，服务器侧密钥注册时间已有一段时间，其中密钥可以在 KRA 上生成，而不是在智能卡上本地生成。从 PKI v.10.5 开始，我们采用类似的机制来解决浏览器 keygen deficiency 问题。密钥会在服务器(KRA)上生成，然后安全地传输回 PKCSxdg 中的客户端。

注意

强烈建议您使用 Server-Side Keygen 机制只用于加密证书。

13.8.2. 功能亮点

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

13.8.3. 安装配置

注意

除了设置 Server-Side Keygen 的 CA 外，还需要 KRA 实例。

注意

在这种情况下，当 CA 和 KRA 共享 Tomcat 实例时，不需要执行以下步骤来导入传输证书。

安装 CA 和 KRA 实例后，在使用独立 Tomcat Web 服务器实例时，您需要将 KRA 的传输证书添加到 CA 的 nssdb 中。

首先，关闭 CA

Systemctl stop pki-tomcatd@<ca_instance_name>.service
e.g.
# Systemctl stop pki-tomcatd@pki-ca.service

将 KRA 的传输证书导出到文件中

查找并导出 KRA 传输证书：

grep "kra.transport.cert=" /var/lib/pki/<kra_instance_name>/kra/conf/CS.cfg | sed 's/kra.transport.cert=//' > <kra transport cert file>
e.g.
# grep "kra.transport.cert=" /var/lib/pki/pki-kra/kra/conf/CS.cfg | sed 's/kra.transport.cert=//' > /tmp/kraTransport.cert

使用 CA 的 CS.cfg 中指定的别名将 KRA 的传输证书导入到 CA 的 nssdb 中

列出传输证书别名：

grep "ca.connector.KRA.transportCertNickname" /var/lib/pki/<ca_instance_name>/ca/conf/CS.cfg
e.g.
# grep "ca.connector.KRA.transportCertNickname" /var/lib/pki/pki-ca/ca/conf/CS.cfg
ca.connector.KRA.transportCertNickname=KRA transport cert

使用以上步骤中列出的 nickname 导入：

certutil -d /var/lib/pki/<ca_instance_name>/alias -A -t “,,” -n <transportNickName> -i <kra transport cert file>
e.g.
# certutil -d /var/lib/pki/pki-ca/alias -A -t “,,” -n "KRA transport cert" -i /tmp/kraTransport.cert

启动 CA

systemctl start pki-tomcatd@<ca_instance_name>.service
e.g.
# Systemctl start pki-tomcatd@pki-ca.service

13.8.4. 配置集配置

默认情况下，提供了两个默认配置文件 caServerKeygen_UserCert 和 caServerKeygen_DirUserCert，以允许在服务器端生成密钥的位置。但是，带有正确输入、输出和策略集的任何配置集都可以转换为服务器端 keygen 配置集。

Server-Side Keygen 配置文件必须包含以下组件：

13.8.4.1. 输入

input.i1.class_id=serverKeygenInputImpl

13.8.4.2. 输出

output.o1.class_id=pkcs12OutputImpl

13.8.4.3. policyset

生成的 PKCS12 的密码可使用以下策略强制实施：

policyset.userCertSet.11.constraint.class_id=p12ExportPasswordConstraintImpl
policyset.userCertSet.11.constraint.name=PKCS12 Password Constraint
policyset.userCertSet.11.constraint.params.password.minSize=20
policyset.userCertSet.11.constraint.params.password.minUpperLetter=2
policyset.userCertSet.11.constraint.params.password.minLowerLetter=2
policyset.userCertSet.11.constraint.params.password.minNumber=2
policyset.userCertSet.11.constraint.params.password.minSpecialChar=2
policyset.userCertSet.11.constraint.params.password.seqLength=6
policyset.userCertSet.11.constraint.params.password.maxRepeatedChar=3
policyset.userCertSet.11.default.class_id=noDefaultImpl
policyset.userCertSet.11.default.name=No Default

此策略允许设置：

password.minSize - passwor'd 的最小大小；
password.minUpperLetter - 最小大写字母数；
password.minLowerLetter - 最小小写字母数；
password.minNumber - 最小数字数；
password.minSpecialChar - 最小标点字符数；
password.seqLength - 无法重复的子字符串序列的大小；
password.maxRepeatedChar - maximum of repeating per character;

如果约束不包含特定的配置，它会从 CS.cfg 读取选项。如果名称不同，前缀 password. 被 passwordChecker 替代。CS.cfg 中的配置用于所有密码，但每个配置集都可以覆盖来允许更强大的密码或更弱的密码。

密钥类型和密钥大小参数可以被配置为 exemplified:

policyset.userCertSet.3.constraint.class_id=keyConstraintImpl
policyset.userCertSet.3.constraint.name=Key Constraint
policyset.userCertSet.3.constraint.params.keyType=-
policyset.userCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096,nistp256,nistp384,nistp521
policyset.userCertSet.3.default.class_id=serverKeygenUserKeyDefaultImpl
policyset.userCertSet.3.default.name=Server-Side Keygen Default
policyset.userCertSet.3.default.params.keyType=RSA
policyset.userCertSet.3.default.params.keySize=2048
policyset.userCertSet.3.default.params.enableArchival=true

13.8.4.4. 身份验证

两个默认的服务器端 keygen 注册配置集在身份验证机制中有所不同，其中

caServerKeygen_UserCert.cfg: 包含 "auth.class_id=" 的空值，这意味着通过这个配置集注册请求需要从 CA 代理批准。
caServerKeygen_DirUserCert.cfg: 包含 "auth.instance_id=UserDirEnrollment"，这意味着用户需要用户传递 LDAP uid/password 身份验证；Such 身份验证机制被视为自动证书颁发，因为它不需要 CA 代理的每请求批准。

可以通过在上述 caServerKeygen_DirUserCert.cfg 配置文件中将 auth.instance_id 指令设置为任何兼容身份验证插件类来配置自动批准。以下是 CS.cfg 中此类配置示例：

auths.instance.UserDirEnrollment.dnpattern=
auths.instance.UserDirEnrollment.ldap.basedn=ou=People,dc=example,dc=com
auths.instance.UserDirEnrollment.ldap.ldapconn.host=host.example.com
auths.instance.UserDirEnrollment.ldap.ldapconn.port=389
auths.instance.UserDirEnrollment.ldap.ldapconn.secureConn=false
auths.instance.UserDirEnrollment.ldap.maxConns=
auths.instance.UserDirEnrollment.ldap.minConns=
auths.instance.UserDirEnrollment.ldapByteAttributes=
auths.instance.UserDirEnrollment.ldapStringAttributes=mail
auths.instance.UserDirEnrollment.pluginName=UidPwdDirAuth

13.8.5. 使用 Server-Side Keygen 注册证书

默认的 Sever-Side Keygen 注册配置文件可在 EE 页面中找到，在"List Certificate Profiles"选项卡下找到：

13.8.5.1. 使用服务器端密钥生成手动用户双使用证书注册

图 13.2. 需要代理手动批准的 server-Side Keygen rollment

13.8.5.2. 使用服务器端密钥生成目录验证的用户双注册

图 13.3. Server-Side Keygen Enrollment，它会在成功 LDAP uid/pwd 身份验证时自动批准

无论请求如何被批准，Server-Side Keygen Enrollment 机制都需要 End Entity 用户输入 PKCSkcs 软件包的密码，其中包含发布的证书以及服务器发布后生成的加密私钥。

重要

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

批准注册请求时，将生成 PKCSGRESS 软件包，以及

如果是手动批准，Pepax 文件将返回到用于批准请求的 CA 代理；然后，代理会预期将 PKCSkcs 文件转发到用户。
如果是自动批准，则 PKCSmtc 文件将返回到提交请求的用户

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

收到 PKCSburst 后，用户可以使用 cli （如 pkcs12util ）将 PKCSmtc 文件导入到她/继承用户内部证书/密钥数据库。例如用户的 Firefox nss 数据库。

13.8.6. 密钥恢复

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

13.8.7. 其它信息

13.8.7.1. KRA 请求记录

注意

由于此机制的性质，在配置集 中启用Archival 参数时，每个 Server-Side keygen 请求记录有两个 KRA 请求：

一个用于请求类型 "asymkeyGenRequest"
- 此请求类型无法在 KRA 代理页的"List Requests"中过滤；一个选择"Show All Requests"来查看列出它们。
一个用于请求类型"recovery"

13.8.7.2. 审计记录

如果启用了，可以观察一些审计记录：

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 （尚未实施）

返回顶部