关于 CSR 和 SSL 证书的问题
Questions about CSR and SSL Certificates
我正在连接到外部服务器并正在制作 CSR 以从他们那里接收一些证书，对此我有一些疑问。
一些教程指出您应该保存私钥，因为这将在安装证书期间使用。但是，当使用 Windows 证书管理器 (certmgr.msc) 时，我认为它会在后台生成私钥，并且生成的 CSR 文件不包含任何私钥。所以在那种情况下，我根本无法访问任何私钥，除非我可以从稍后收到的证书中导出它？我还觉得安装证书不需要私钥，因为它只是导入到证书存储中？如果是这样，私钥除了生成 public 密钥外还有什么用吗？
我也想知道证书可以使用的位置。该证书似乎只能在创建 CSR 的服务器上使用。但是，我的应用程序将 运行 在 Azure 上，那么我如何才能获得可以在云中使用的证书？
最后一个问题：证书提供商提供了三个证书，一个根证书，一个中间证书和一个"actual"证书。这些不同证书的用途是什么？
感谢对此过程的任何见解或指导。那里有很多指南，但其中许多似乎在某种程度上相互矛盾。
(certmgr.msc) I think [] generates the private key under the hood,
正确。您生成密钥 和 CSR，将后者发送给 CA，并且（我们希望！）取回包含您的 public 密钥和身份的证书（对于 SSL/TLS 你的身份是你的一个或多个域名），加上任何需要的链证书（通常是一个中间证书和一个根证书，但这可能会有所不同）。您将证书导入 certmgr，它将它与现有的、存储的但隐藏的私钥相匹配，以生成 对 的 cert+privatekey，现在可见和可用。
要在 Windows 程序（如 IIS）中使用它，您还需要 chain 证书，见下文，在您的商店中——对于这些只是证书而不是私钥，您没有也无法获得。如果您使用已建立的 public CA，例如 Comodo、GoDaddy、LetsEncrypt，它们的根目录通常 已经在您的商店中 ，并且如果您使用雇主的 CA 运行由于电子邮件等其他原因，他们的根可能已经在您的商店中；如果没有，你应该添加它。中间体可能已经在您的商店中，也可能不在您的商店中，如果没有，您应该添加它（它们）。
I was also under the impression that a private key is not needed for installation of the certificate as it is just imported into the certificate store?
它是需要的，但您没有提供它，因为它已经存在。
It seems that the certificate can only be used on the server that the CSR was created. However, my application will run on Azure so how can I get a certificate that can be used in the cloud?
最初，它只能在生成 CSR 和私钥的系统上使用。但是使用 certmgr 您可以导出证书 和 私钥的 组合 ，以及可选的证书链（导出向导调用 'path'） , 到 PKCS12/PFX 文件。该文件可以复制到其他 Windows 系统并导入 and/or 由其他类型的软件使用或导入到其他类型的软件，如 Java（例如 Tomcat 和 Jboss/Wildfly） 、Apache、Nginx 等
但是请注意，您可以使用证书的一个或多个域名，或者可能与（单级）通配符匹配的一系列名称是在颁发证书时确定的，以后不能更改（除非获得新证书）。
The certificate provider supplies three certificates, one root, one intermediate and one "actual" certificate. What is the purpose of these different certificates?
证书颁发机构按层次结构排列。 运行——特别是安全——根 CA 既困难又昂贵。因此，终端实体（如您）的证书不是由根直接颁发的，而是由从属或中间 CA 颁发的。有时会有不止一级的下级或中级。因此，当您的服务器 使用 此证书来证明其身份时，为了让浏览器或其他客户端 验证 （并因此接受）您的证书需要提供 'chain' 证书，每个证书都由下一个签名，它将您的证书链接到受信任的根。正如我所说，一种中间体很常见；这意味着您的服务器需要发送自己的证书，该证书由中间密钥签名，加上由根密钥签名的中间证书。实际上不需要发送根，因为客户端已经在 他们的 信任库中拥有它，但它可能是，并且在使用它之前自己验证链也是可取的。即使你不发送它，你也需要有根。
我正在连接到外部服务器并正在制作 CSR 以从他们那里接收一些证书，对此我有一些疑问。
一些教程指出您应该保存私钥，因为这将在安装证书期间使用。但是，当使用 Windows 证书管理器 (certmgr.msc) 时，我认为它会在后台生成私钥，并且生成的 CSR 文件不包含任何私钥。所以在那种情况下，我根本无法访问任何私钥，除非我可以从稍后收到的证书中导出它？我还觉得安装证书不需要私钥，因为它只是导入到证书存储中？如果是这样，私钥除了生成 public 密钥外还有什么用吗？
我也想知道证书可以使用的位置。该证书似乎只能在创建 CSR 的服务器上使用。但是，我的应用程序将 运行 在 Azure 上，那么我如何才能获得可以在云中使用的证书？
最后一个问题：证书提供商提供了三个证书，一个根证书，一个中间证书和一个"actual"证书。这些不同证书的用途是什么？
感谢对此过程的任何见解或指导。那里有很多指南，但其中许多似乎在某种程度上相互矛盾。
(certmgr.msc) I think [] generates the private key under the hood,
正确。您生成密钥 和 CSR，将后者发送给 CA，并且（我们希望！）取回包含您的 public 密钥和身份的证书（对于 SSL/TLS 你的身份是你的一个或多个域名），加上任何需要的链证书（通常是一个中间证书和一个根证书，但这可能会有所不同）。您将证书导入 certmgr，它将它与现有的、存储的但隐藏的私钥相匹配，以生成 对 的 cert+privatekey，现在可见和可用。
要在 Windows 程序（如 IIS）中使用它，您还需要 chain 证书，见下文，在您的商店中——对于这些只是证书而不是私钥，您没有也无法获得。如果您使用已建立的 public CA，例如 Comodo、GoDaddy、LetsEncrypt，它们的根目录通常 已经在您的商店中 ，并且如果您使用雇主的 CA 运行由于电子邮件等其他原因，他们的根可能已经在您的商店中；如果没有，你应该添加它。中间体可能已经在您的商店中，也可能不在您的商店中，如果没有，您应该添加它（它们）。
I was also under the impression that a private key is not needed for installation of the certificate as it is just imported into the certificate store?
它是需要的，但您没有提供它，因为它已经存在。
It seems that the certificate can only be used on the server that the CSR was created. However, my application will run on Azure so how can I get a certificate that can be used in the cloud?
最初，它只能在生成 CSR 和私钥的系统上使用。但是使用 certmgr 您可以导出证书 和 私钥的 组合 ，以及可选的证书链（导出向导调用 'path'） , 到 PKCS12/PFX 文件。该文件可以复制到其他 Windows 系统并导入 and/or 由其他类型的软件使用或导入到其他类型的软件，如 Java（例如 Tomcat 和 Jboss/Wildfly） 、Apache、Nginx 等
但是请注意，您可以使用证书的一个或多个域名，或者可能与（单级）通配符匹配的一系列名称是在颁发证书时确定的，以后不能更改（除非获得新证书）。
The certificate provider supplies three certificates, one root, one intermediate and one "actual" certificate. What is the purpose of these different certificates?
证书颁发机构按层次结构排列。 运行——特别是安全——根 CA 既困难又昂贵。因此，终端实体（如您）的证书不是由根直接颁发的，而是由从属或中间 CA 颁发的。有时会有不止一级的下级或中级。因此，当您的服务器 使用 此证书来证明其身份时，为了让浏览器或其他客户端 验证 （并因此接受）您的证书需要提供 'chain' 证书，每个证书都由下一个签名，它将您的证书链接到受信任的根。正如我所说，一种中间体很常见；这意味着您的服务器需要发送自己的证书，该证书由中间密钥签名，加上由根密钥签名的中间证书。实际上不需要发送根，因为客户端已经在 他们的 信任库中拥有它，但它可能是，并且在使用它之前自己验证链也是可取的。即使你不发送它，你也需要有根。