关于证书签名过程的java问题

发布于 2024-10-19 18:34:15 字数 534 浏览 12 评论 0原文

我对用 java 创建由 CA 签名的有效证书的过程感到困惑。
我知道java有工具keytool来创建公钥-私钥和证书。
它还支持 JKS 和 PKCS#12。
因此,我们可以创建一个带有公钥-私钥对和证书的密钥库,例如
keytool -genkey -keyalg RSA -alias aCert -keystore someKeystore.keystore 这将创建一个带有证书(自签名)的密钥库。
到目前为止我明白了。
我可以导出 csr 请求的证书发送给 CA(例如 Verisign),当然不需要私钥。
在这部分之后我迷失了。
CA 将对其进行签名,我必须将其重新导入到我的密钥库中?这将替换密钥库中已有的原始证书?
但它仍然是自签名的。
颁发者不应该是 CA 本身吗?但这怎么可能?我只发送公钥而不发送证书?
请帮忙清理流程吗?
更新
签署证书的 CA(例如 Verisign)也是颁发者吗?或者它可以签署颁发者==主题的证书?
谢谢

I am confused on the process to create a valid certificate,signed by a CA, in java.
I know that java has the tool keytool to create public-private keys and certificates.
Also it supports JKS and PKCS#12.
So one can create a keystore with a public-private key pair and a certificate e.g.
keytool -genkey -keyalg RSA -alias aCert -keystore someKeystore.keystore
This will create a keystore with a certificate (self-signed).
So far I understand.
I can export the certificate for a csr request to send to a CA e.g. Verisign, without the private key of course.
After this part I am lost.
The CA will sign it and I will have to re-import it to my keystore?This will replace the original certificate already in keystore?
It will still be self-signed though.
Shouldn't the issuer be the CA itself?But then how is this possible?I just send the public key only and not a certificate?
Any help on clearing the process please?
UPDATE:
Is the CA signing the certificate (e.g. Verisign) also the issuer?Or it can sign a certificate that the issuer==subject?
Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

甜扑 2024-10-26 18:34:15

在创建 CSR 方面,您是正确的。您将使用类似以下内容:

$ keytool -certreq -alias myalias -file myalias.csr -keystore keystore

生成 CSR,其中包含:

  • 您的公钥(从自签名证书中提取)
  • 专有名称(即请求证书的实体的名称)

,并由您的签名者签名私钥。然后,CA 生成一个新证书,其中包含:

  • 主题 = 您的 DN(来自 CSR 或使用您在申请过程中提供的详细信息自动生成)
  • 颁发者 = CA 的 DN
  • 公钥 = 来自 CSR

,您需要将其导入回您的证书密钥库,替换原始自签名证书:

$ keytool -import -alias myalias -keystore keystore -file myalias.crt

CA 通常会使用中间证书签署您的新证书,而该中间证书又由可信根签名;在这种情况下,您应该在自己的证书之前导入中间证书:

$ keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore

编辑: keytool 文档中的这个模糊部分非常清晰(其中谈到证书“链”,这仅指中间证书将您的链接链接到根):

keytool 可以创建和管理密钥库“密钥”条目,每个条目都包含私钥和关联的证书“链”。链中的第一个证书包含与私钥对应的公钥。

首次生成密钥时(请参阅 -genkey 子命令),链开始时包含一个元素,即自签名证书。自签名证书是颁发者(签名者)与主体(其公钥由证书验证的实体)相同的证书。每当调用 -genkey 子命令生成新的公钥/私钥对时,它还会将公钥包装到自签名证书中。

稍后,在生成证书签名请求 (CSR)(请参阅 -certreq 子命令)并将其发送到证书颁发机构 (CA) 后,将导入来自 CA 的响应(请参阅 -import),并且自签名证书被证书链取代。链的底部是由 CA 颁发的证书(回复),用于验证主体的公钥。链中的下一个证书是验证 CA 公钥的证书。

You're correct up to the point of CSR creation. You'll use something like this:

$ keytool -certreq -alias myalias -file myalias.csr -keystore keystore

to generate a CSR, which contains:

  • your public key (extracted from the self-signed cert)
  • the Distinguished Name (i.e. the name of the entity for whom the cert is requested)

and is signed with your private key. The CA then generates a new certificate with:

  • subject = your DN (either from the CSR or auto-generated using details you supplied during the application process)
  • issuer = the CA's DN
  • public key = from the CSR

which you need to import back into your keystore, replacing the original self-signed cert:

$ keytool -import -alias myalias -keystore keystore -file myalias.crt

Often CAs will sign your new certificate using an intermediate certificate which is in turn signed by a trusted root; in this case you should import the intermediate certificate before your own:

$ keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore

Edit: this obscure section from keytool's documentation is surprisingly clear (where it talks about a 'chain' of certificates, this just refers to the intermediate certificates that link yours to the root):

keytool can create and manage keystore "key" entries that each contain a private key and an associated certificate "chain". The first certificate in the chain contains the public key corresponding to the private key.

When keys are first generated (see the -genkey subcommand), the chain starts off containing a single element, a self-signed certificate. A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate). Whenever the -genkey subcommand is called to generate a new public/private key pair, it also wraps the public key into a self-signed certificate.

Later, after a Certificate Signing Request (CSR) has been generated (see the -certreq subcommand) and sent to a Certification Authority (CA), the response from the CA is imported (see -import), and the self-signed certificate is replaced by a chain of certificates. At the bottom of the chain is the certificate (reply) issued by the CA authenticating the subject's public key. The next certificate in the chain is one that authenticates the CA's public key.

鹿! 2024-10-26 18:34:15

CA 签署证书后,它就不再是自签名的。自签名证书的颁发者==主题。当 CA 对其进行签名时,颁发者就成为 CA,它对应于 CA 自己的证书中的主题,而该证书又由另一个颁发者签名,...因此您拥有一个证书链,该证书链终止于已受信任的根中在您的信任库中。

After the CA signs the cert it ceases to be self-signed. A self-signed certificate has issuer == subject. When the CA signs it, issuer becomes the CA, which corresponds to the subject in the CA's own certificate, which in turn is signed by another issuer, ... so you have a certificate chain, that terminates in a trusted root that is already in your truststore.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文