密钥保管库证书入门

本指南可帮助你开始密钥保管库中的证书管理。

此处介绍的方案列表：

• 创建第一个密钥保管库证书
• 使用与密钥保管库合作的证书颁发机构创建证书
• 使用未与密钥保管库合作的证书颁发机构创建证书
• 导入证书

证书是复杂的对象

证书由三种相互关联的资源组成：证书元数据、密钥和机密，并共同构成一个 密钥保管库 证书。

创建第一个密钥保管库证书

在 密钥保管库（KV）中创建证书之前，必须成功完成先决条件步骤 1 和 2，同时用户或组织必须拥有一个现有的 key vault。

步骤 1： 证书颁发机构 （CA） 提供商

• 作为 IT 管理员、PKI 管理员或管理证书颁发机构帐户的人员，加入 (例如 Contoso 这种公司) 是使用 密钥保管库 证书的先决条件。
  以下 CA 是当前与 密钥保管库 合作的提供商。 有关详细信息，请参阅 合作 CA 供应商。
  • DigiCert - 密钥保管库通过 DigiCert 提供 OV TLS/SSL 证书。
  • GlobalSign - 密钥保管库提供具有 GlobalSign 的 OV TLS/SSL 证书。

步骤 2： CA 提供商的帐户管理员创建凭据，以便由 密钥保管库 用于注册、续订和使用 TLS/SSL 证书。

Step 3a： Contoso 管理员以及拥有证书的 Contoso 员工（密钥保管库用户）可以从管理员那里获取证书，也可以直接从具有 CA 的帐户获取证书。

• 通过设置证书颁发者资源，开始在密钥保管库中添加凭据操作。 证书颁发者是一个在 Azure 密钥保管库（KV）中以 CertificateIssuer 资源形式表示的实体。 它用于提供有关 KV 证书源的信息;颁发者名称、提供程序、凭据和其他管理详细信息。

  • 例如，MyDigiCertIssuer

    • Provider
    • 凭据 - CA 帐户凭据。 每个 CA 都有自己的特定数据。

    有关使用 CA 提供程序创建帐户的详细信息，请参阅 密钥保管库 博客的相关文章。

步骤 3b： 为通知设置 证书联系人。 这是密钥保管库用户的联系人。 密钥保管库不强制执行此步骤。

注意 - 此过程（通过 步骤 3b）是一次性操作。

使用与 密钥保管库 合作的 CA 创建证书

步骤 4： 以下说明对应于上图中的绿色编号步骤。
（1） - 在上图中，您的应用程序正在创建一个证书，首先会在密钥保管库中创建一个密钥。
（2） - 密钥保管库向 CA 发送 TLS/SSL 证书请求。
（3）- 您的应用程序通过循环和等待过程轮询 密钥保管库，以检测证书的完成。 当密钥保管库收到具有 x509 证书的 CA 响应时，证书创建将完成。
（4） - CA 使用 X509 TLS/SSL 证书响应密钥保管库的 TLS/SSL 证书请求。
（5）- 通过合并 CA 的 X509 证书，新的证书创建已完成。

密钥保管库用户 - 通过指定策略创建证书

• 根据需要重复

• 策略约束

  • X509 属性
  • 键属性
  • 提供者引用 -> 例如 MyDigiCertIssuer
  • 续订信息 -> 例如，到期前 90 天

• 证书创建过程通常是一个异步过程，涉及轮询密钥保管库，了解创建证书作的状态。
  获取证书操作

  • 状态：已完成、失败并显示错误信息或已取消
  • 由于创建的延迟，可以启动取消操作。 取消可能有效或可能无效。

与集成 CA 关联的网络安全和访问策略

密钥保管库服务将请求发送到 CA（出站流量）。 因此，它与已启用防火墙的密钥保管库完全兼容。 密钥保管库不与 CA 共享访问策略。 CA 必须配置为独立接受签名请求。 集成可信证书颁发机构的指南

导入证书

或者 ， 证书可以导入密钥保管库 - PFX 或 PEM。

导入证书 - 要求 PEM 或 PFX 位于磁盘上并具有私钥。

• 必须指定：保管库名称和证书名称（策略是可选的）

• PEM/PFX 文件包含 KV 可以分析和用于填充证书策略的属性。 如果已指定证书策略，KV 将尝试匹配 PFX/PEM 文件中的数据。

• 导入完成后，后续作将使用新策略（新版本）。

• 如果没有进一步的操作，则密钥保管库做的第一件事是发送过期通知。

• 此外，用户可以编辑策略，该策略在导入时正常运行，但包含未在导入时指定任何信息的默认值。 例如，没有颁发者信息

我们支持的导入格式

Azure 密钥保管库支持 .pem 和 .pfx 证书文件，用于将证书导入 Key Vault。 我们支持以下 PEM 文件格式的导入类型。 单个 PEM 编码证书以及 PKCS#8 编码的未加密密钥，其格式如下：

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

-----BEGIN 私钥-----

-----END PRIVATE KEY-----

导入证书时，需要确保密钥包含在文件本身中。 如果私钥以不同的格式单独使用，则需要将密钥与证书组合在一起。 某些证书颁发机构提供不同格式的证书，因此在导入证书之前，请确保它们采用 .pem 或 .pfx 格式。

我们支持的合并 CSR 的格式

Azure 密钥保管库支持具有以下标头的 PKCS#8 编码证书：

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

使用 CA 创建未与密钥保管库合作的证书

此方法允许与其他 CA 合作，而不是密钥保管库的合作伙伴提供商，这意味着你的组织可以使用所选 CA。

以下步骤说明对应于上图中的绿色字母步骤。

（1）- 在上图中，您的应用程序正在创建证书，这包括首先在您的密钥保管库中创建一个密钥。

（2） - 密钥保管库向应用程序返回证书签名请求（CSR）。

（3） - 应用程序将 CSR 传递给所选 CA。

（4） - 所选的 CA 使用 X509 证书进行响应。

（5） - 您的应用程序通过合并来自 CA 的 X509 证书来完成新证书的创建。