Fatal编程技术网
  • certificate/
  • Certificate 仅适用于一个应用程序的x509证书-选择哪个OID

Certificate 仅适用于一个应用程序的x509证书-选择哪个OID

certificate

Certificate 仅适用于一个应用程序的x509证书-选择哪个OID,certificate,x509certificate,Certificate,X509certificate,我正在创建将为用户创建证书的应用程序。我想以某种方式标记这些证书，以便以后可以在windows用户证书存储中按以下类别搜索它们： 应用程序GUID（或名称-我想知道此证书适用于我的应用程序） 证书角色（管理证书或用户证书） 用户电子邮件 我知道最后一个我应该用“E=J”。Doe@mail.com“或OID编号”1.2.840.113549.1.9.1=J。Doe@mail.com" 但我不知道为应用程序GUID和证书角色选择哪个OID 或者我应该使用“密钥使用”字段 我不知道这是否重要，但证

我正在创建将为用户创建证书的应用程序。我想以某种方式标记这些证书，以便以后可以在windows用户证书存储中按以下类别搜索它们：

  • 应用程序GUID（或名称-我想知道此证书适用于我的应用程序）
  • 证书角色（管理证书或用户证书）
  • 用户电子邮件
我知道最后一个我应该用“E=J”。Doe@mail.com“或OID编号”1.2.840.113549.1.9.1=J。Doe@mail.com" 但我不知道为应用程序GUID和证书角色选择哪个OID

或者我应该使用“密钥使用”字段

我不知道这是否重要，但证书将用于对我的应用程序进行身份验证并解密数据库中的数据

有什么标准的方法吗？

好的，几个小时后，我得到了这样的东西

所有证书将按主题字段进行识别。 对于管理员证书，它将如下所示：

CN=<My application Name> Administrator,OU=Administrator,OU=<My application Name>,O=<My company Name>

CN=Administrator，OU=Administrator，OU=，O=
以及为用户

E=<User email>,CN=<User email>,OU=User,OU=<My application Name>,O=<My company Name>

E=，CN=，OU=User，OU=，O=
如果有人有更好的主意，我愿意听取建议：-）

嗯。。。所以我的想法是，您计划向每个用户颁发证书，并计划为每个应用程序生成不同的证书。因此，如果您有10个用户，每个用户使用3个应用程序，那么您将获得30个证书

然后证书还描述了用户在应用程序中的角色，以及用户的电子邮件

说实话，我不会把这些信息都放在证书里。PKI很难提供-用户通常很难设置证书，重新颁发证书是一件痛苦的事情。一般来说，PKI部署策略会尽量减少必须颁发的证书数量，并在这一数量与风险之间取得平衡

我所见过的最典型的场景是，给用户一个单独的证书，用于标识自己。证书包括用户的姓名和电子邮件。但它通常不包括用户的角色或特定的应用程序。相反，该信息在访问控制服务器上进行管理，用户访问系统时会查询该服务器。这样，用户可以更改可用的角色和应用程序，而无需重新颁发证书。像Active Directory或Select Access这样的产品可以做这种事情

将每次使用分成一个单独的cetificate的原因是为了具体控制某种类型的风险。例如，如果单个用户在一台机器上执行高风险操作，而在另一台更具潜在风险的机器上执行低风险操作，则可能会有两个证书（每台机器一个）的情况，因此您可以在不禁用高风险功能的情况下撤销低风险证书。如果您计划在同一台计算机上存储所有证书，那么只为每个用户分发一个证书会更容易

也就是说，如果您仍然认为需要为每个用户、每个角色、每个应用程序颁发1个证书，我建议您找到一种方法，将应用程序GUID、角色和电子邮件塞入可分辨名称中

您不会从密钥使用或扩展密钥使用中获得太多收益-这些具有非常特定的价值，我怀疑它们是否能传达您想要描述的信息。此外，其他各种应用程序也以特定的方式使用它们，因此如果您需要与其他应用程序集成，这可能会变得很棘手。

您的任务相当复杂。要解决这个问题，最好的方法是使用openssl在内部证书颁发机构上做一些工作。请记住，分配给您引用的实体的PKI遵循以下规则：

  • 可分辨名称：用于标识签发证书的用户或实体。使用它来标识单个证书中的两个不同实体是不正确的：您的用户和应用程序。这两个实体可以在两个不同的地方识别

  • 密钥用法是一个8位的位字段，用于定义密钥的用法。每个位都有其预定义的含义，不能用于其他目的

    • 我建议你：

  • 将应用程序GUID设置为x509扩展名。您可以将ID和个人ID分配给该扩展并查询它。如果你在内部使用OID，你可以利用你想要的任何价值。如果您计划分发您的证书，您可以从IANA获得您自己的OID

  • 按照PKI的建议，将邮件放在主题为alternative mail的字段中

  • 对于管理员或用户，您可以添加第二个x509扩展或创建证书树。主CA证书、管理员CA证书和用户CA证书。每个管理员证书都将由管理员CA签署，每个用户证书都将由用户CA签署

    • 实际上，我们将为每个用户提供一张智能卡，用于少数几个具有公共“管理员”（即我们的财务总监）的特别敏感的应用程序。我只有两种类型的管理员证书和用户证书。所有用户证书都由管理员签名。所有其他角色都在数据库中定义，并由管理员签名。正如你所说的那样——数据泄露的风险很大——这就是为什么我们要采取这些特殊措施来保护它们。考虑到PKI的惯例，这听起来是一个极不寻常的设置。通常，证书颁发机构（CA）处理所有证书签名，高权限用户使用其凭据操作CA。这样做是为了限制风险-CA可以比管理员证书受到更严格的保护。此外，使用PKI标准概念可以使用证书撤销技术，如CRL和OCSP。传统的PKI在风险管理方面经过了很好的审查，您最好不要重新发明轮子。