现在，当我几乎将
自签名证书的生成添加到基于PKCS＃11 cryptoarmpkcs令牌的加密工作站上并准备开始撰写本文时，我收到了这样的一封信：
我们是UZNIREK CA，我们很难以pkcs＃11格式发布EGAIS的ES，门户网站不了解Znamerek CSP格式的ES，我们请您提供帮助。
我不知道使用EGAIS的所有复杂性，但是由于它是PKCS＃11，因此我建议使用cryptoarmpkcs实用程序来
生成请求，并在从CA收到令牌后为令牌安装证书。 我收到的答案有点让人分心：
las，事实是我们通过CryptoPro CSP在RuToken 2.0上记录了ES，但是在所有适当的设置下，EGIAS门户在关键介质上没有看到ES，客户联系了我们以寻求支持，但我们发现问题不在于此。密钥证书是用这种格式写的，这是手册dev.rutoken.ru/display/KB/RU1051
。
我（不仅是我）已经写了很多次使用俄语俄罗斯加密技术作为
普通闪存驱动器的加密令牌。 当密钥和证书没有作为PKCS＃11对象到达令牌时，就是这种情况。 可惜的是他们没有采纳建议，甚至没有尝试创建请求。 但是后来我决定搁置一切，弄清楚如何以及以何种方式签发EGAIS Rosalkogolregulirovanie证书。 而且，我们将仅考虑PKCS＃11加密令牌。 最大的失望是仅通过Windows和IE浏览器访问EGAIS。 另一方面，如果证书请求具有用于相应令牌的驱动程序/库，则也可以在任何OS下执行证书请求的生成和证书安装。
至少PKCS＃11令牌JaCarta，RutokenECP-2.0，LS11SW2016软件令牌，甚至
云令牌都在MS Windows，Linux和OS X上受支持。不仅限于这些OS。
实际上，我们必须向EGAIS的开发人员致敬。 他们提出了一种有趣的技术，该技术允许访问使用存储在加密令牌上的个人证书（证书加密钥对），并支持俄罗斯密码，并保护RSA证书上的通道。 虽然如果他们说A，那么一个人可以说B，即 使用GOST-ov算法保护频道。 唯一可悲的是，所有这些都仅针对MS Windows（或者我误会了？）或Internet Explorer量身定制。 用于生成EGAIS证书请求的实用程序与特定令牌绑定。
但是cryptoarmpkcs实用程序是多平台的。 而且，它能够与支持俄罗斯密码的任何PKCS＃11密码令牌一起使用。
那么，EGAIS证书请求的特殊性是什么？ 主要功能是必须在证书持有人（DN主题）的专有名称中强制存在一个附加字段unstucturedName（UN）（oid-1.2.840.113549.1.9.2）。 如果证书的所有者是个人企业家，则在此字段中写“ KPP =”行；如果证书的所有者是法人实体，则在此字段中写此行：
PPC = reason_code_of_tax_account_account：
在这方面，证书请求选项卡首页上的要求已添加了EGAIS按钮：
另一个功能是EGAIS证书的持有者可以是FSRAP声明系统的被许可人（oid-1.2.643.3.6.78.4.4）。 创建请求时也需要考虑以下因素：
填写证书申请的所有字段并确认数据正确之后，将生成密钥对并创建请求：
如果查看该请求，则可以在其中看到oid-s（扩展密钥用法），这是EGAIS Rosalkogolregulirovanie所必需的：
在这里，您应该注意（在上一个屏幕截图中）密钥对标签。 在PKCS＃11术语中，这是公用密钥和专用密钥的CKA_LABEL属性。 通过这样的方案，EGAIS查询生成器从CenterInform FSUE为JaCarta创建标签（键名）：
传统上，三重
证书x公钥x私钥
令牌上的令牌通过
属性CKA_ID连接
：
指定CKA_ID的最常见方法是使用公钥值中的哈希函数值。 这是用于链接NSS（网络安全服务）项目中使用的三个对象的方法。 同时，SHA1算法用作哈希函数。
不幸的是，CKA_LABEL和CKA_ID都可以在任何时候以任何值进行设置/更改。 因此，证书总是有可能与他人的私钥相关联。 无需解释其后果。
通常，是否有严格的数学算法可让您将三元组CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY连接成一个整体？
是的，存在基于令牌的密码机制（CKM_）的算法。
不幸的是（尽管可以客观地理解），它考虑了通过上述方法形成的通过CKA_LABEL的三元组束。 此外，对于私钥和公钥，SKA_ID以类似的方式形成。 对于密钥，这只是一场灾难，因为 但是CKA_ID和CKA_LABEL都没有以任何方式绑定到密钥本身。 这也适用于证书安装在令牌上之后。 如果按照传统方式将CKA_ID作为来自公共密钥的哈希来构成，则您始终可以检查两者是否匹配，那么以上述方式设置CKA_ID和CKA_LABEL时，就无法做到这一点。
可能会出现问题，但是如何检查私钥的符合性？ 答案很简单-通过相对于私钥计算公钥的值。 至于证书，其公钥的值自然就在其中。 此外，证书本身包含证书持有者（证书主题密钥标识符）和证书发布者（证书颁发机构密钥标识符）的CKA_ID值：
最不愉快的是，在安装证书时，不是检查私钥的存在，而仅公钥就足够了。 在这种情况下，将安装证书，但是上面没有私钥。 另一个问题。 这是TIN进行的公钥搜索。 想象一个人有一个TIN和几个用于各种证书的密钥。 属于哪一个？ 之后，很明显，JaCarta要求
只有一个证书和一对密钥：
此错误可能与证书重复有关。 在管理员模式下的JaCarta Single Client中，在GOST选项卡上，输入PIN码后，应该可见一个公用密钥，一个专用密钥和证书。 在这种情况下，密钥重复是可见的。 您需要删除多余的。 将介质重新插入USB连接器，然后尝试再次安装UTM。 如果错误仍然存在，请根据链接1初始化Jacarta，然后再次执行生成过程。
我们希望可以消除这一缺点。 您可能会询问EGAIS的cryptoarmpkcs实用程序如何安装证书。 为了与JaCarta完全兼容，我们保留了密钥的CKA_ID和CKA_LABEL相同的思想。 但是仅在将证书安装在令牌上并将其绑定在密钥对中之后。 在此之前，密钥对CKA_ID保持等于来自公共密钥的哈希值。
安装证书后，可以使用它来
签署文档 。
您可以
在此处阅读有关自签名证书的
信息 ：
