除此之外，PKIX 规范定义了一个扩展（给定证书的一部分），该扩展指示证书是否可以用作 CA 证书，即是否可以用作另一个证书的颁发者。
由此，您可以在最终实体证书（您要为用户或服务器验证的证书）和您信任的 CA 证书之间构建证书链。您的服务的最终实体证书和您信任的 CA 证书之间可能存在中间 CA 证书（由其他 CA 证书颁发）。您并不严格需要顶部的根 CA（自签名 CA 证书），但情况经常如此（如果您愿意，您可以选择直接信任中间 CA 证书）。
对于您的用例，如果您为特定服务生成自签名证书，则它是否具有 CA 标志（基本约束扩展）并不重要。您需要它是一个 CA 证书才能颁发其他证书（如果您想构建自己的 PKI）。如果您为此服务生成的证书是 CA 证书，那么它不会造成任何损害。更重要的是您可以将客户端配置为信任该特定服务器的证书的方式（例如，浏览器应该让您很容易地做出显式例外）。如果配置机制遵循 PKI 模型（不使用特定例外），由于不需要构建一条链（只需一个证书），您应该能够直接导入证书作为信任锚的一部分您的客户端，无论是否是 CA 证书（但这可能取决于客户端的配置机制）。
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate. The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate. An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same. By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
如果您需要更多证书 (C)，则需要创建自签名 CA (ssCA)。 如果您需要单个证书，则只需创建自签名证书 (SSC)。 要信任单个证书 (SSC)，您需要将 SSC 安装到客户端上的根密钥库中。 要同时信任多个证书，您需要创建一个自签名 CA (ssCA)，然后将 ssCA 安装到客户端上的根密钥库中。
If you need more certificates (C), you need to create a self-signed CA (ssCA). If you need a single certificate, you can just create a self-signed certificate (SSC). To trust the single certificate (SSC), you need to install SSC into the root keystore on your client. To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
您必须始终拥有一个根CA，该CA有一个可用于签署较低级别证书的密钥和一个可嵌入到客户端上接受的根证书中并用于验证较低级别证书以检查它们的根证书是有效的。自签名仅意味着您是您自己的 CA。每当创建自签名证书时，您都会创建一个 ca，然后使用该 CA 签署站点证书。
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.
发布评论
评论（5）
首先，关于密钥和证书（关于“CA密钥”）之间的区别，在谈论公钥证书（通常是X.509）时使用3个部分：公钥、私钥和证书。
公钥和私钥形成一对。您可以使用私钥进行签名和解密，可以使用公钥进行验证（签名）和加密。公钥的目的是分发，而私钥的目的是保密。
公钥证书是公钥和各种信息（主要是关于密钥对所有者的身份，即控制私钥的人）之间的组合，该组合使用公钥颁发者的私钥进行签名证书。
X.509 证书具有主题专有名称和颁发者专有名称。颁发者名称是颁发证书的实体的证书的主题名称。自签名证书是一种特殊情况，其中颁发者和主体相同。
通过签署证书的内容（即颁发证书），颁发者断言其内容，特别是密钥、身份（主体）和各种属性（可能表明证书的使用意图或范围）之间的绑定。证书）。
除此之外，PKIX 规范定义了一个扩展（给定证书的一部分），该扩展指示证书是否可以用作 CA 证书，即是否可以用作另一个证书的颁发者。
由此，您可以在最终实体证书（您要为用户或服务器验证的证书）和您信任的 CA 证书之间构建证书链。您的服务的最终实体证书和您信任的 CA 证书之间可能存在中间 CA 证书（由其他 CA 证书颁发）。您并不严格需要顶部的根 CA（自签名 CA 证书），但情况经常如此（如果您愿意，您可以选择直接信任中间 CA 证书）。
对于您的用例，如果您为特定服务生成自签名证书，则它是否具有 CA 标志（基本约束扩展）并不重要。您需要它是一个 CA 证书才能颁发其他证书（如果您想构建自己的 PKI）。如果您为此服务生成的证书是 CA 证书，那么它不会造成任何损害。更重要的是您可以将客户端配置为信任该特定服务器的证书的方式（例如，浏览器应该让您很容易地做出显式例外）。如果配置机制遵循 PKI 模型（不使用特定例外），由于不需要构建一条链（只需一个证书），您应该能够直接导入证书作为信任锚的一部分您的客户端，无论是否是 CA 证书（但这可能取决于客户端的配置机制）。
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
两个选项都有效，选项 2 更简单。
当您需要多个证书时，最好选择选项 1（设置您自己的 CA）。在公司中，您可以设置自己的 CA 并将该 CA 的证书安装在所有客户端的根密钥库中。然后，这些客户端将接受您的 CA 签署的所有证书。
选项 2（在没有 CA 的情况下自签名证书）更容易。如果您只需要一个证书，那么这就足够了。将其安装在客户端的密钥库中即可完成。但是，当您需要第二个证书时，您需要在所有客户端上再次安装该证书。
以下是包含更多信息的链接：创建证书颁发机构和自签名 SSL 证书
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
您可以通过 openssl x509 -noout -text -in $YOUR_CERT 来查看文件内容的差异：
在您的自签名 CA 中，您可以看到：
而在您的自签名证书中，它是：
You can
openssl x509 -noout -text -in $YOUR_CERTto see the differences between files contents:In your self-signed CA, you can see：
And in your self-signed certificate, it's:
如果您需要更多证书 (C)，则需要创建自签名 CA (ssCA)。
如果您需要单个证书，则只需创建自签名证书 (SSC)。
要信任单个证书 (SSC)，您需要将 SSC 安装到客户端上的根密钥库中。
要同时信任多个证书，您需要创建一个自签名 CA (ssCA)，然后将 ssCA 安装到客户端上的根密钥库中。
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
您必须始终拥有一个根CA，该CA有一个可用于签署较低级别证书的密钥和一个可嵌入到客户端上接受的根证书中并用于验证较低级别证书以检查它们的根证书是有效的。自签名仅意味着您是您自己的 CA。每当创建自签名证书时，您都会创建一个 ca，然后使用该 CA 签署站点证书。
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.