有关CSR和SSL证书的问题 [英] Questions about CSR and SSL Certificates

问题描述

我正在连接到外部服务器，并且正在进行CSR接收来自它们的一些证书，对此我有一些疑问.

I'm in the process of connecting to an external server and am making a CSR to receive some certificates from them, and I have some questions regarding this.

某些教程指出您应该保存私钥，因为它将在证书安装期间使用.但是，当使用Windows证书管理器(certmgr.msc)时，我认为它会在后台生成私钥，并且生成的CSR文件不包含任何私钥.因此，在那种情况下，除非可以从以后收到的证书中导出它，否则我将根本无法访问任何私钥?我还给人一种印象，因为证书只是导入到证书存储中，所以不需要专用密钥来安装证书?如果是这样的话，私钥除了生成公钥之外还有其他用途吗?

Some tutorials state that you should save the private key as this will be used during installation of the certificate. However when using the Windows certificate manager (certmgr.msc) I think it generates the private key under the hood, and the resulting CSR-file does not contain any private key. So in that case I won't have access to any private key at all, unless I can export it from the certificate I receive later? 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? If that's the case, does the private key have any use besides generating the public key?

我还想知道证书可以使用的位置.似乎证书只能在创建CSR的服务器上使用.但是，我的应用程序将在Azure上运行，因此如何获得可在云中使用的证书?

I was also wondering about the location the certificate can be used. 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?

最后一个问题:证书提供者提供三个证书，一个根，一个中间和一个实际"证书.这些不同证书的目的是什么?

Last question: The certificate provider supplies three certificates, one root, one intermediate and one "actual" certificate. What is the purpose of these different certificates?

赞赏对此过程的任何见解或指导.那里有很多指南，但是其中许多指南似乎在某种程度上相互矛盾.

Appreciate any insight or guiding to this process. There are a tons of guides out there, but many of them seem to contradict each other in some way or another.

推荐答案

(certmgr.msc)我认为[]在后台生成私钥，

(certmgr.msc) I think [] generates the private key under the hood,

正确.您生成密钥和 CSR，将其发送给CA，(我们希望！)取回包含您的公钥和身份的证书(对于SSL/TLS，您的身份是您的域名)，以及所有需要的链证书(通常是一个中间证书和一个根证书，但这可能有所不同).您将证书导入到certmgr中，该证书与现有的已存储但隐藏的私钥匹配，以生成cert + privatekey的 pair 对，该私钥现在可见且可用.

Correct. You generate the key and CSR, send the latter to the CA, and (we hope!) get back a cert containing your publickey and identity (for SSL/TLS your identity is your domain name or names), plus any needed chain certs (usually one intermediate and a root, but this can vary). You import the cert to certmgr, which matches it up with the existing, stored but hidden privatekey to produce a pair of cert+privatekey which is now visible and usable.

要在Windows程序(如IIS)中使用此证书，您还需要存储中的 chain 证书(请参见下文)，因为这些证书仅是私钥而不是私钥(s)，您没有，也没有得到.如果您使用已建立的公共CA(例如Comodo，GoDaddy，LetsEncrypt)，则其根目录通常已经在您的商店中，并且如果您使用由雇主运行的CA，则其根目录可能已经在您的商店中诸如电子邮件之类的原因；如果没有，您应该添加它.中间产品可能已经存在或可能尚未在您的商店中，如果没有，您应该添加它们.

To use this in a Windows program, like IIS, you also need the chain cert(s), see below, in your store -- for these just the cert(s) not the privatekey(s), which you don't have and can't get. If you use an established public CA like Comodo, GoDaddy, LetsEncrypt their root is usually already in your store, and if you use a CA run by your employer their root may well be already in your store for other reasons such as email; if not you should add it. The intermediate(s?) may or may not already be in your store and if not you should add it(them).

我还给人一种印象，因为证书只是导入到证书存储中，所以不需要专用密钥来安装证书?

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 is needed, but you don't provide it, because it's already there.

似乎证书只能在创建CSR的服务器上使用.但是，我的应用程序将在Azure上运行，因此如何获得可在云中使用的证书?

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可以将证书和私钥的组合以及可选的证书链(导出向导称为路径")导出到PKCS12/PFX文件.该文件可以复制到其他Windows系统上并导入到其他Windows系统上，和/或由Java(例如Tomcat和Jboss/Wildfly)，Apache，Nginx等其他类型的软件使用或导入.

Initially, it is usable only on the system where the CSR and privatekey were generated. But using certmgr you can export the combination of the certificate and privatekey, and optionally the cert chain (which export wizard calls 'path'), to a PKCS12/PFX file. That file can be copied to and imported on other Windows systems and/or used by or imported to other types of software like Java (e.g. Tomcat and Jboss/Wildfly), Apache, Nginx, etc.

但是请注意，您可以将证书用于哪个或多个域名(或可能与一个(单级)通配符匹配的名称范围)是在颁发证书时确定的，并且以后不能更改(除非通过获取新证书).

Note however that the domain name or names, or possibly a range of names matching a (single-level) wildcard, that you can use the cert for is determined when the cert is issued and can't be subsequently changed (except by getting a new cert).

证书提供者提供三个证书，一个根，一个中间和一个实际"证书.这些不同证书的目的是什么?

The certificate provider supplies three certificates, one root, one intermediate and one "actual" certificate. What is the purpose of these different certificates?

证书颁发机构按层次结构排列.运行(尤其是保护)根CA既困难又昂贵.因此，最终实体(如您)的证书不是直接由根颁发，而是由下级或中间CA颁发.有时存在多个级别的下属或中级.因此，当您的服务器使用该证书来证明其身份时，为了使浏览器或其他客户端验证(并因此接受)您的证书，您需要提供一个链"的证书，每个证书都由下一个签名，它将您的证书链接到受信任的根目录.就像我说的，一种中间体很常见.这意味着您的服务器需要发送自己的证书(由中间密钥签名)和中间证书(由根密钥签名).根实际上不必发送，因为客户端已经在其信任库中将其发送了，但是可能已经发送了，并且还希望在使用它之前亲自验证链，为此您需要即使没有发送，也要有根.

Certificate Authorities are arranged in a hierarchy. Running -- particularly securing -- a root CA is difficult and expensive. As a result certs for end-entities (like you) are not issued directly by the root, but by a subordinate or intermediate CA. Sometimes there is more than one level of subordinate or intermediate. Thus when your server uses this certificate to prove its identity, in order for the browser or other client to validate (and thus accept) your cert you need to provide a 'chain' of certificates, each one signed by the next, which links your cert to the trusted root. As I said, one intermediate is common; this means your server needs to send its own cert, which is signed by the key in the intermediate, plus the intermediate cert, which is signed by the key in the root. The root needn't actually be sent, because the client already has it in their truststore, but it may be, and it is also desirable to validate the chain yourself before using it and for that you need to have the root even if you don't send it.

这篇关于有关CSR和SSL证书的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！