【问题标题】:iKeyman personal certificate dissapearediKeyman 个人证书消失
【发布时间】:2015-09-14 17:11:10
【问题描述】:

我创建了证书请求,将此请求发布给了权威机构,并取回了签名证书。使用 iKeyman 我已添加所有签名者证书并成功将签名证书接收到我的密钥数据库中。我看到添加个人证书时如何删除请求。我关闭了 iKeyman,当我再次打开它时,个人证书。不再上市?并且我无法再次收到,因为请求不再存在。如何重新创建相同的请求,或者有任何其他方式将个人证书添加到我的密钥数据库中。

cmets 2015 年 9 月 15 日更新
runmqakm -cert -list 显示证书列表
操作系统 - Windows Server 2008 R2
IKeyman 版本 8.0.382.CMS 提供程序版本 2.45。
执行所有操作的帐户是本地管理员。

我的输出:

C:\ProgramData\IBM\MQ\ssl>runmqakm -cert -list all -db key.kdb 
5724-H72 (C) Copyright IBM Corp. 1994, 2014. 
Source database password : ****** 
Certificates found 
* default, - personal, ! trusted, # secret key 
! XXX-Root-CA 
! XXX-Intermediate-CA 
! XXX-Issuing-CA 
! ibmwebspheremqusapp1u 

C:\ProgramData\IBM\MQ\ssl>runmqakm -certreq -list all -db key.kdb 
5724-H72 (C) Copyright IBM Corp. 1994, 2014. 
Source database password : ****** 
No certificate requests were found

【问题讨论】:

  • 这里没有太多信息。你能补充你的问题吗?例如,您是否使用runmqakm -cert -listrunmqakm -certreq -list 验证了这一点?文件权限是什么? Windows 还是 Linux? MQ 版本? GSKit 版本?显然,所描述的行为不应该发生,所以我们需要更多细节来弄清楚它为什么会发生或者它是否是一个错误。
  • 是的,runmqakm -cert -list 显示证书列表,操作系统 - Windows Server 2008 R2,IKeyman 版本 8.0.382.CMS 提供程序版本 2.45。执行所有操作的帐户都是本地管理员。
  • 我的输出:C:\ProgramData\IBM\MQ\ssl>runmqakm -cert -list all -db key.kdb 5724-H72 (C) Copyright IBM Corp. 1994, 2014. 源数据库密码: ****** 找到的证书 * 默认, - 个人, !受信任,# 密钥! XXX-根-CA! XXX-中级-CA! XXX-发行-CA ! ibmwebspheremqusapp1u C:\ProgramData\IBM\MQ\ssl>runmqakm -certreq -list all -db key.kdb 5724-H72 (C) 版权所有 IBM Corp. 1994, 2014。源数​​据库密码:****** 无证书请求被发现

标签: ssl ibm-mq mq


【解决方案1】:

您是正确的,KDB 没有个人证书,也没有杰出​​的 CSR。但是,如果带有标签 ibmwebspheremqusapp1u 的证书应该是个人证书,则现在将其加载为受信任的证书。如所述,无法从 KDB 中恢复私钥,如果没有备份文件,则该证书是不可恢复的。您可以期望的最好结果是 CA 是一种允许客户重新加密证书的 CA。

没有发出runmqakm -cert -add 是不可能到达这个状态的。预期的命令应该是runmqakm -cert -receive,它将来自 CA 的响应与原始未完成的 CSR 结合起来,并创建一个完整的个人证书。要么已经完成,要么这不是在其中创建 CSR 的 KDB,因为正如您所指出的,没有出色的 CSR。

假设没有导致此问题的 GSKit 错误,并且这是在其中创建 CSR 的同一个 KDB,然后在成功接收 CSR 后的某个时间点,个人证书被删除并使用 @987654324 重新添加来自 CA 的响应@。替代方案是 CSR 被明确删除(我猜你会记得如果是这样的话)或者 GSKit 有一个令人讨厌和危险的错误,你是迄今为止唯一发现的人。

从屏幕的这一侧很难确定 GSKit 错误或用户错误,但是从您的角度来看是可能的 a) 防止这种情况再次发生; b) 可能做出明确的决定。 “我该怎么做,”你问?

一旦 KDB 或 JKS 中包含私钥、CSR 或个人证书,请务必在对其发出命令之前对其进行备份。您始终可以恢复受信任的证书,但私钥或任何包含私钥的东西都是独一无二且不可替代的。不要冒险对现有的唯一副本进行操作而丢失它。

例如,在提交 CSR 并收到 CA 的响应后,将 key.* 文件复制到 key.[timestamp].* 并将备份文件标记为只读,然后再重新接收 CSR。如果 @987654327 @ 成功然后你就可以走了。如果没有,您可以将备份复制到坏 kdb 上,或者复制到一组新的 kdb 文件中(永远不要对备份进行操作!)并尝试重新创建问题以确定它是错误还是用户错误。

具有出色 CSR 的备份 KDB 将始终让您回到创建 CSR 后的状态,因此您可以根据需要多次回溯您的步骤。如果您可以可靠地重新创建错误并认为它是 GSKit 错误,请与 IBM 一起打开 PMR。这是一个不太可能发生的情况,但我知道它会发生,因为我曾经发现一个 GSKit 错误,它会炸毁整个密钥库。因此,我盲目地坚持“更改前备份”的策略。和你一样,我也学得很辛苦。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-01-04
    • 1970-01-01
    • 2019-11-13
    • 2012-06-18
    • 1970-01-01
    • 2020-09-27
    • 2011-08-06
    • 1970-01-01
    相关资源
    最近更新 更多