在 AIQUM 中生成 CSR 不起作用

最后更新
另存为PDF

Views:: 1

Visibility:: Public

Votes:: 0

Category:: active-iq-unified-manager

Specialty:: om

Last Updated:

适用于

Active IQ Unified Manager (AIQUM) 9.x
Red Hat Enterprise Linux (RHEL)
证书签名请求 (CSR)

问题

在 RHEL 上运行的 AIQUM 中，导航到General → HTTPS Certificates → Download HTTPS Certificate Signing Request不执行任何操作——没有提供 CSR 文件供下载，GUI 也没有返回可见的错误。
在点击时查看/opt/netapp/essentials/jboss/server/onaro/log/ocumserver.log显示BouncyCastle签名程序失败：

ERROR [admin] [default task-3118] [c.n.o.r.m.e.GlobalExceptionHandler] cannot create signer: Key must not be null
org.bouncycastle.operator.OperatorCreationException: cannot create signer: Key must not be null
at deployment.dfm-app.war//org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.build(Unknown Source)
at deployment.dfm-app.war//com.netapp.dfm.app.common.security.CertificateManagerImpl.createCertificationRequest

(CertificateManagerImpl.java:110)
…
Caused by: java.security.InvalidKeyException: Key must not be null

相同的错误在浏览器 HAR 捕获中也可见，作为500响应返回给 Download HTTPS Certificate Signing Request REST 调用。
对 JBoss keystore 执行keytool -list时，可能会显示在安装/升级时创建的条目，其密钥长度或签名算法异常（例如，产品内自签名条目应为 2048 位，但实际为 3072 位 RSA 密钥）
这表明 GUI 期望用于签名的私钥材料在 keystore 中缺失或不匹配。

原因

这是一个特定于客户主机的环境问题：
强制模式下的 SELinux 或其他主机强化可能会阻止 AIQUM jboss / umadmin 用户读取或重写生成 CSR 流所需的密钥库文件。
Ansible、CIS 强化手册或其他配置管理代理等安全自动化工具会定期重置文件所有权、模式或 SELinux 标签在 AIQUM 目录上——最重要的是在 /opt/netapp/essentials/jboss/server/onaro/cert/ 和 /opt/netapp/data/ocie/ 上。当这种情况发生时，GUI 流无法再加载私钥，BouncyCastle 会获得一个 null 密钥，并且 CSR 生成在 UI 中静默失败，堆栈跟踪如上所示在 ocumserver.log 中。
这不是 AIQUM 产品代码路径本身的缺陷——相同的 GUI 流在 SELinux/Ansible 尚未更改密钥库文件的全新安装上可以正常工作。

解决方案

警告

直接与生产中的 AIQUM 密钥库配合使用 keytool 会带来风险—在进行更改之前，始终拍摄虚拟机快照和 /opt/netapp/essentials/jboss/server/onaro/cert/ 和 /opt/netapp/data/ocie/ 的副本。

目标： 确认密钥库/证书对象一致并具有有效的私钥材料，然后重新运行支持的 CLI 助手，或者作为回退，使用 keytool 匹配的算法和密钥长度重新创建密钥库条目。

检查当前密钥库条目的签名算法和密钥长度 — 用于创建密钥库条目的算法和密钥长度必须与 CSR 签名时 CA 预期的算法和密钥长度相匹配：

keytool -list -v -keystore /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore -storepass $(/opt/netapp/essentials/bin/elytronstore.sh /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore jboss $(cat /opt/netapp/essentials/conf/server.properties | grep "keystore.token" | cut -c 16-))

请注意 Signature algorithm name（例如SHA256withRSA）和Subject Public Key Algorithm / key 大小（例如2048-bit RSA key）。
验证两个密钥库副本是否同步。JBoss 密钥库和 OCIE 密钥库应该是逐字节相同的—如果不是，则 GUI 流可以达到"Key must not be null"条件：

cksum /opt/netapp/data/ocie/server.keystore
cksum /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore

两个 cksum值必须匹配。如果不匹配，请从已知良好的备份中恢复或从 JBoss 副本中重新同步。
使用支持的cert.sh助手重新生成密钥库条目：

/opt/netapp/essentials/bin/cert.sh createcustom <FQDN><email><Org><City><Country> 2048 730 '<SAN list, comma separated>' 'true'

这是首选路径，因为它使 JBoss 和 OCIE 密钥库副本保持同步，并重用 AIQUM 管理的凭据存储。
如果 cert.sh 不适合（例如，您需要不同的别名/算法），请直接回退到 keytool。首先识别别名：

keytool -list -keystore /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore -v -storepass $(/opt/netapp/essentials/bin/elytronstore.sh /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore jboss $(cat /opt/netapp/essentials/conf/server.properties | grep "keystore.token" | cut -c 16-))

然后生成一个密钥对（匹配 CA 预期的算法/密钥长度）和一个 CSR：

keytool -genkeypair -alias keyentry -keystore /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore -storetype JKS -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname "CN=<FQDN>" -ext san=dns:<FQDN>,dns:<short-name>,ip:<mgmt-ip> -validity 730 -storepass $(/opt/netapp/essentials/bin/elytronstore.sh /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore jboss $(cat /opt/netapp/essentials/conf/server.properties | grep "keystore.token" | cut -c 16-))

keytool -certreq -alias keyentry -keystore /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore -storetype JKS -sigalg SHA256withRSA -file server.csr -storepass $(/opt/netapp/essentials/bin/elytronstore.sh /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore jboss $(cat /opt/netapp/essentials/conf/server.properties | grep "keystore.token" | cut -c 16-)) -keypass $(/opt/netapp/essentials/bin/elytronstore.sh /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore jboss $(cat /opt/netapp/essentials/conf/server.properties | grep "keystore.token" | cut -c 16-))

获取由 CA 签名的证书并确认返回的证书具有与 CSR 相同的签名算法和密钥长度（此处不匹配将在导入时重现相同的"Key must not be null"症状）。
将签名的证书导入回密钥库：

keytool -importcert -alias keyentry -keystore /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore -storetype JKS -storepass $(/opt/netapp/essentials/bin/elytronstore.sh /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore jboss $(cat /opt/netapp/essentials/conf/server.properties | grep "keystore.token" | cut -c 16-)) -trustcacerts -file </path_to_the_cert_file/cert_name>.crt

或者通过受支持的帮助程序：

/opt/netapp/essentials/bin/cert.sh import </path_to_the_cert_file/cert_name>.crt

重新同步 OCIE 并重新启动 AIQUM 服务，以便 JBoss 和 OCIE 加载新的密钥库。
解决环境根本原因，以免问题再次发生：
- 使用 getenforce 确认 SELinux 状态，如果是 Enforcing，请在 /var/log/audit/audit.log 中查看针对 AIQUM 目录的 AVC 拒绝并添加所需的策略/标签。
- 审核针对 AIQUM 主机运行的 Ansible/配置管理 playbook，并从通用 chmod/chown/restorecon 步骤中排除 AIQUM 拥有的路径。

合作伙伴备注

合作伙伴备注_text

追加信息

Generate CSR GUI 流所触及的文件：
- /opt/netapp/essentials/bin/cert.sh
- /opt/netapp/essentials/bin/certificatemanager/platform-base-display-key.jar
- /opt/netapp/data/ocie/server.keystore
- /opt/netapp/essentials/jboss/standalone/data/jbossCredStore.cs
- /opt/netapp/essentials/bin/elytronstore.sh
- /opt/netapp/essentials/conf/server.properties
- /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore
两个 server.keystore 文件（在 /opt/netapp/data/ocie/ 和 /opt/netapp/essentials/jboss/server/onaro/cert/ 下）必须具有相同的 cksum。

内部参考

源案例： 2010649653 (UBS，RHEL 上的 AIQUM 9.16)
CPE 升级： CPE-12443 — AIQUM 9.16 — 从 GUI 生成 CSR 失败：BouncyCastle "无法创建签名者：密钥不得为空" (UBS，2010649653)
Bug ID： CAIQUM-7005
补丁：可通过 mysupport 获得固定的 keystoresetup.jar — AIQUM 9.18D21
两个 server.keystore 副本必须具有相同的 cksum：

[root@scs001105021 ~]# cksum /opt/netapp/data/ocie/server.keystore
1751053047 9941 /opt/netapp/data/ocie/server.keystore
[root@scs001105021 ~]# cksum /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore
1751053047 9941 /opt/netapp/essentials/jboss/server/onaro/cert/server.keystore

在源案例中，客户的 Ansible / hardening 修改了 AIQUM 路径上的文件权限，并且 SELinux 处于强制模式——两者都有影响
在远程会话期间使用的临时 setenforce 0仅用于确认 SELinux 的影响，之后已恢复；长期修复方案是从强化剧本中排除 AIQUM 路径或添加所需的 SELinux 策略。