文件.keystore和CAKey.pem在SSL中的作用？ [英] Role of files .keystore and CAKey.pem in SSL?

问题描述

我成功地通过http从https上获取了我的web应用程序。
实际上我怀疑在这个过渡阶段遇到的两个文件的作用。我可以看到两个密钥文件，一个是.keystore，另一个是CAKey.pem。我特别想知道他们在什么时候进入画面。在server.xml中，我找到了一个atrributes keystoreFile（其值是keystore的位置）和keystorePass（我在生成.keystore文件期间给出的密码值）的条目，而在ApplicationConfig.xml中我找到了两个属性，即openSSLLocation （我可以看到openssl目录的值），第二个属性是password（对于哪个值，我在生成CAKey.pem文件时给出了密码值）。

i was successfully to take my webapplication on https from http. Actually i have doubts about the roles of two files that came across during this transition phase. I can see two key files one is .keystore and another is CAKey.pem. I specifically want to know the at what point of time they come in to picture. In server.xml i find a entry of atrributes keystoreFile(for which value is location of keystore) and keystorePass(value for which is password i had given during generation of .keystore file) while in ApplicationConfig.xml i find a two attributes i.e openSSLLocation(against which i can see the value of openssl directory) and second attribute is password (against which value is what i had given the value of password during generation of CAKey.pem file).

想知道这些文件包含哪些内容并在SSL中扮演角色？

Want to know specifically what these file contain and play role in SSL?

编辑我穿过bruno发出的链接。我也通过另一个信息链接链接，即 http：/ /www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/ 。通过这两个链接之后我的理解是kestore文件包含SSL证书的详细信息（如果我们使用授权的CA像verisign那么它们提供128位加密，这可能是由java keytool命令证书提供的默认密钥存储不会）。在包含私钥的证书的基础上，加密发生。 对吗？正如versign链接所指出的，最后数字签名也作为确认发出。 不确定此证书是否有任何目的或只是链接中指出的确认？ CACert.pem，CAKey.pem等文件与数字证书相关？

Edit i went thru the link which bruno pinted out. I also went thru another informative link link i.e http://www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/. Now my understanding after going thru thhese two links is kestore file contains the details of SSL certificate (if we use authorized CA like verisign they provide 128 bit encryption which probably default key store brovided by java keytool command certificates does not). On the basis of this certificate containing private key, encryption happens. Right? As pointed in versign link , at last digital signature is also issued as acknowledgement. Not sure Does this certificate has any purpose or just acknowledgement as pointed in link? Files like CACert.pem, CAKey.pem are related to digital certificates?

修改2

以下是我为SSL执行的步骤

1）从 http://www.slproweb.com下载Win32OpenSSL_Light-0_9_8t /products/Win32OpenSSL.html 并安装

2）在OpenSSL安装目录中，创建子目录private。证书颁发机构的私钥将存储在此处。
在OpenSSL安装目录中，创建子目录newcerts。 CA签署的新证书将存储在此处。
在OpenSSL安装目录中，创建一个名为index.txt的空文件。 OpenSSL将其签名证书数据库保存在该文件中。
从OpenSSL安装目录的bin / PEM / demoCA子目录中，将文件serial复制到OpenSSL安装目录。打开复制的串行文件并将其编辑为00并保存。每个新的CA签名证书的序列号都取自此文件的内容，每次签署证书时该内容都会增加。

2) In the OpenSSL installation directory, create subdirectory private. The Certificate Authority's private key will be stored here. In the OpenSSL installation directory, create subdirectory newcerts. New certificates signed by the CA will be stored here. In the OpenSSL installation directory, create an empty file named index.txt. OpenSSL keeps its signed certificates database in that file. From the subdirectory bin/PEM/demoCA of the OpenSSL installation directory, copy the file serial to the OpenSSL installation directory. Open the copied serial file and edit it to read 00 and save. Each new CA-signed certificate's serial number is taken from this file's content, which is incremented each time a certificate is signed.

3）在openssl.cfg .Did中，以下更改
dir = c：/ openssl< - 这是OpenSSL安装目录
certificate = $ dir / private / cacert.pem
#crl = $ dir / crl.pem

3) In openssl.cfg .Did the following changes dir = c:/openssl <-- This is the OpenSSL installation directory certificate = $dir/private/cacert.pem #crl = $dir/crl.pem

4）使用命令$ b $创建自签名证书b cd / d％OPENSSL_HOME％
openssl req -new -x509 -days 2000 -keyout private\CAKey.pem -out private\CACert.pem -config bin\openssl.cnf

4) Create Self-signed Certificate with command cd /d "%OPENSSL_HOME%" openssl req -new -x509 -days 2000 -keyout private\CAKey.pem -out private\CACert.pem -config bin\openssl.cnf

5）将证书PEM文件转换为DER编码文件
cd / d％OPENSSL_HOME％
openssl x509 -in private\CACert.pem - out private\CACert.cer -outform DER
此命令在private子目录中创建文件CACert.cer。

5)Convert the certificate PEM file to a DER encoded file cd /d "%OPENSSL_HOME%" openssl x509 -in private\CACert.pem -out private\CACert.cer -outform DER This command creates file CACert.cer in the private subdirectory.

6）修改Java根证书

6) Modify Java Root Certificates

cd％JAVA_HOME％
keytool -import -keystore jre \ lib\security\cacerts -alias AppOpenSSLCert -file％OPENSSL_HOME％\ private\cacert.cer

cd %JAVA_HOME% keytool -import -keystore jre\lib\security\cacerts -alias AppOpenSSLCert -file %OPENSSL_HOME%\private\cacert.cer

这会将我们的自签名CA证书添加到Java的可信CA证书，保存在Java JDK安装目录中的文件jre\lib\security\cacerts中。
我们的自签名CA证书存储在别名AppOpenSSLCert下。

This adds our self-signed CA certificate to Java's trusted CA certificates, which are kept in file jre\lib\security\cacerts in the Java JDK installation directory. Our self-signed CA certificate was stored under the alias AppOpenSSLCert.

根据文档它应该有效（即我尝试点击URL https）但它没有用。为了使它工作，我不得不再运行一个命令，即

As per documentation it should have worked(i.e i tried hitting the URL with https) but it did not work . To make it work I had to run one more command i.e

7）
C：\Program Files \ Java \ _ddk1.6.0_23> keytool -genkey -alias tomcat -keyalg生成.keystore文件的RSA（（当将客户端发出https请求时，将发送SSL证书，客户端在truststore和private中匹配此证书）密钥）

7) C:\Program Files\Java\jdk1.6.0_23>keytool -genkey -alias tomcat -keyalg RSA which generated .keystore file((which will have SSL certificate which will be send when client makes https request and client matches this certificates in truststore and private key)

最后我在server.xml中进行了更改，它运行了
keystoreFile =c：/。keystore
keystorePass =changeit

Finally i made changes in server.xml and it worked keystoreFile="c:/.keystore" keystorePass="changeit"

这就是为什么我想到了整个混乱。如果我们使用第7步生成的.keystore文件所指向的证书，那么我做的步骤的目的是什么从1到6（CAKey.pem和CACert.pem文件）。无论我对SSL的理解如何，我想我应该在server.xml中没有提到.keystore（在步骤7中生成），但是在步骤1-6中某些其他密钥库可能在某处生成但不确定文件名是什么以及它在何处生成？

verisign链接中的最后一个问题。它讨论了两个证书，即SSL证书和数字证书。 SSL证书和数字证书适合上述情况的地方？

推荐答案

从Java的角度来看，你应该先尝试了解密钥库和信任库（两者都是用于不同目的的密钥库）之间的区别。

From a Java point of view, you should first try to understand the difference between keystore and truststore (both of which are keystores used for different purposes).

JSSE中没有默认密钥库，但是某些应用程序默认使用 $ HOME / .keystore ：这是包含证书的内容，您拥有私钥。

There is no default keystore in the JSSE, but some applications use $HOME/.keystore by default: this is what contains your certificate, for which you have the private key.

相反，信任库确定您愿意信任哪些远程证书。它包含许多CA证书，在遇到新证书时可以为其建立证书路径。如果存在这样的路径（并且如果激活了证书未被撤销），则此（先验的）未知证书被接受为受信任。

In contrast, the truststore determines which remote certificates you're willing to trust. It contains a number of CA certificates to which a certification path can be established when encountering a new certificate. If there is such a path (and provided the certificate isn't revoked if this is activated), this (a priori) unknown certificate is accepted as trusted.

听起来就像你使用的程序一样，你创建了自己的证书颁发机构，因此你最终会得到一个CA证书文件及其私钥（很可能是 CAkey.pem 文件）。这应仅用于使用此CA颁发新证书。

It sounds like the procedure you've used consisted of created your own Certification Authority, hence you'll end up with a CA certificate file and its private key (which is likely to be that CAkey.pem file). This should only be used to issue new certificates with this CA.

如果我们使用授权CA，如verisign，则提供128位加密
可能是由java keytool命令提供的默认密钥库
证书没有）。

if we use authorized CA like verisign they provide 128 bit encryption which probably default key store brovided by java keytool command certificates does not).

这不是以前的证书选择加密密钥大小，这是密码套件。 （ SGC证书的时代结束了。）

It's not the certificate that's used to choose the encryption key size, it's the cipher suite. (The era of SGC certificates is over.)

在SSL / TLS握手期间，服务器证书用于验证服务器（以确保客户端与其想要的服务器通信）与...谈谈并协商一组共享对称密钥（取决于密码套件）：那些是用于加密的密钥。

During the SSL/TLS handshake, the server certificate is used to authenticate the server (to ensure that the client is communicating with the server it wanted to talk to) and to negotiate a set of shared symmetric keys (depending on the cipher suite): those are the ones used for the encryption.

如果你想生成一个对于特定密钥大小的 keytool 证书，请使用 -keysize 2048 （例如）。请注意，这是证书中密钥的大小，而不是用于加密本身的对称密钥的大小。

If you want to generate a certificate with keytool for a specific key size, use -keysize 2048 (for example). Note that this is the size of the key in the certificate, not the size of the symmetric keys used for the encryption itself.

或多或少与<$的命令相同c $ c> keytool 可用于生成CSR以发送给商业CA.无论您使用商业CA还是您自己的CA都没有任何区别w.r.t.加密强度。不同之处在于默认情况下没有人会识别您自己的证书，因此您必须明确地在客户端中导入它。证书主要用于验证您正在与之通信的远程实体的身份。

More or less the same command with keytool can be used to generate a CSR to send to a commercial CA. Whether you use a commercial CA or your own will make no difference w.r.t. the encryption strength. The difference is that no one will recognise your own certificates by default, so you will have to import it in your clients explicitly. The certificates are mainly useful for verifying the identity of the remote entity you're communicating with.

（您可能也对这个问题。）

编辑：

你混合了两个完全不同的程序。

You've mixed two completely different procedures.

您使用OpenSSL所做的是生成您自己的证书颁发机构（CA）。因此，您获得 CAcert.pem 和 CAkey.pem 这些是CA证书及其私钥（用于发布）使用此CA的新证书）。如果您沿着这条路走下去，那么您需要做的就是将 CAcert.pem 作为客户的可信CA证书导入，并且您使用它颁发的证书将是值得信赖。您可能也对OpenSSL的 CA.pl 感兴趣，这是一个包含许多你可能手动完成的程序的脚本。

What you've done with OpenSSL is generate your own Certification Authority (CA). Hence, you get CAcert.pem and CAkey.pem which are the CA certificate and its private key (used for issuing new certificates with this CA). If you go down that route, all you'll need to do is to import CAcert.pem as a trusted CA certificate in your clients, and the certificates you issue with it will be trusted. You may also be interested in OpenSSL's CA.pl, which is a script that wraps many of the procedures you may have done more manually.

OpenSSL无法处理JKS文件，如果没有额外的一些额外的话，这个程序不是很有用脚步。从这里，您可以：

OpenSSL can't deal with JKS files, and this procedure isn't very useful without a few extra steps. From here, you could either:

• 使用OpenSSL为您的服务器生成密钥+证书（CA.pl应该有帮助）。从Java的角度来看，以PKCS＃12格式（ .p12 文件）导出它更容易：然后您就可以直接从Java使用该文件了一个类型 PKCS12的密钥库（ keystoreType =PKCS12在您的配置中）。


• 通过 -certreq 使用 keytool 生成CSR，使用OpenSSL颁发证书（同样，CA.pl应该帮助），将此证书重新导入您的密钥库（通过 keytool ）并使用该JKS商店。

• Generate a key+cert for your server using OpenSSL (CA.pl should help). From a Java point of view, it's easier to export it in PKCS#12 format (.p12 file): you'll then be able to use that file directly from Java as a keystore of type PKCS12 (keystoreType="PKCS12" in your configuration).
• Generate a CSR with keytool via -certreq, issue a certificate using OpenSSL (again, CA.pl should help), re-import this certificate into your keystore (via keytool) and use that JKS store.

如果您只有一台服务器，这可能是最简单的。

This is probably the easiest if you only have one server.

在这种情况下，请按照此答案中所述的步骤操作，并导入使用导出的证书-export 进入客户的信任库（或进入您的浏览器）。

In this case, follow the procedure described in this answer and import the certificate exported with -export into your client's truststore (or into your browser).

verisign链接中的最后一个问题。它讨论了两个证书，即
SSL证书和数字证书。 SSL证书和
数字证书适用于上述情况？

Last question in the verisign link. it talks about two certicates i.e SSL certificate and digital certificate. Where SSL certificate and digital certificate fit in above scenario?

不确定，真的。我找不到它在哪里谈论数字证书。严格来说，没有SSL证书这样的东西，尽管表达式或多或少总是意味着用于SSL / TLS的X.509证书。

Not sure, really. I can't find where it talks about "digital certificate". Strictly speaking there is no such thing as an "SSL certificate", although the expression more or less always means "X.509 certificate used for SSL/TLS".

你可以将X.509证书用于SSL / TLS之外的其他目的，并将SSL / TLS与其他类型的证书一起使用。最常见的是带有SSL / TLS的X.509。

You can use X.509 certificates for other purposes than SSL/TLS and use SSL/TLS with other types of certificates. The most common is X.509 with SSL/TLS.

数字证书也可以包含更广泛的类别，例如OpenPGP证书也可以用于SSL / TLS （例如，参见此答案）。还有属性证书，它们甚至不包含公钥（请勿阅读关于他们，直到你真正了解X.509证书是什么，否则，你会更加困惑。）

"Digital certificate" could also encompass a wider category, for example OpenPGP certificates can also be used for SSL/TLS (see this answer, for example). There are also Attribute Certificates, which don't even contain a public key (don't read about them until you've really understood what X.509 certificates are about, otherwise, you'll be more confused).

我的猜测是，Verisign会使用 SSL证书表示用于SSL的X​​.509证书，也可能表示X.509证书的数字证书用于其他用途，例如电子邮件签名/加密。两者都在PKI的背景下（由Verisign建立）。

My guess though is that Verisign would use "SSL certificate" to mean X.509 certificates for use with SSL and perhaps "digital certificates" for X.509 certificates for other uses as well, such as e-mail signing/encryption. Both would be within the context of a PKI (established by Verisign).

这篇关于文件.keystore和CAKey.pem在SSL中的作用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！