Question

我希望您能帮助确定为什么第5步（接近结束）是必要的。

我有一组有效的步骤可以创建一个keystore.ks，其中包含一个包含本地证书颁发机构证书的链。主tomcat（客户端）和slave tomcat（服务器）之间的HTTPS通信工作;这是伟大的，除了我担心我在奴隶keystore.ks中包括很多。

master tomcat（客户端）有一个truststore.ks，它有一个以这种方式创建的条目：

1）创建一个新私钥和一个新证书（CA）文件（new_ca.pem）：

openssl req -x509 -passout pass:mykeypassword -new -config caConfig.txt -days 7300 
-out new_ca.pem -keyout new_ca_pk.pem

2）导入truststore.ks

keytool -importcert -noprompt -alias myrootca -keypass mykeypassword 
-keystore truststore.ks -storepass changeit -storetype jks -file new_ca.pem

slave tomcat（服务器）有一个keystore.ks，其中包含一个以这种方式创建的条目：

1）生成证书和私钥对：

keytool -genkey -noprompt -dname "CN=10.93.101.33, C=US, O=MyCompany, OU=MyCompany 
Manufacturing, ST=MA, L=MyTown" -validity 7000 -alias tomcat -keypass aPassword 
-keystore keystore.ks -storepass aPassword

2）创建证书签名请求

keytool -certreq -alias tomcat -file 10.93.101.33.csr -keypass aPassword  
-keystore keystore.ks -storepass aPassword

3）签署CSR

openssl ca -batch -passin pass:mykeypassword -config caConfig.txt -days 7000 
-in 10.93.101.33.csr -out 10.93.101.33.crt

4）转换为PEM格式

openssl x509 -in 10.93.101.33.crt -out 10.93.101.33.crt -outform PEM

5）连接文件

cat 10.93.101.33.crt new_ca.pem > 10.93.101.33.chain

6）使用完整的证书链更新密钥库

keytool -import -alias tomcat -noprompt -file 10.93.101.33.chain -keypass aPassword 
-keystore keystore.ks -storepass aPassword

以上步骤确实创建了一个工作系统。客户端tomcat可以通过https与服务器tomcat通信，而不存在信任问题。我关注一些事情，为什么我需要将CA证书添加到服务器tomcat的密钥库？最后，还有一种更简单的方法吗？

感谢您的时间。

----------编辑--------------

完整的caConfig.txt：

HOME            = /home/hammer/hmweb/CertificateGenerator/CACertificate
RANDFILE        = $ENV::HOME/.rnd

dir = $HOME

[ ca ]
default_ca = CA_default

[ CA_default ]
serial = $dir/serial.txt
database = $dir/index.txt
unique_subject = no
new_certs_dir = $dir/newcerts
certificate = $dir/new_ca.pem
private_key = $dir/cakey.pem
crl = $dir/crl.pem
default_days = 7300
default_crl_days = 3650         # how long before next CRL
default_md = sha1
preserve = no
email_in_dn = no
policy = policy_match

x509_extensions = usr_cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options

# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

####################################################################
[ req ]
default_bits = 2048
default_keyfile = cert.key
string_mask = MASK:0x2002
utf8 = yes
prompt = no
distinguished_name = req_distinguished_name
policy = policy_anything

x509_extensions = v3_ca # The extensions to add to the self signed cert

####################################################################

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE


# This will be displayed in Netscape's comment listbox.
nsComment           = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

[ req_distinguished_name ]
countryName         = US
stateOrProvinceName     = MA
localityName            = MyTown
0.organizationName      = MyCompany
organizationalUnitName      = MyCompany Manufacturing
commonName          = !!COMMON_NAME_REPLACE_ME!!

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
subjectKeyIdentifier = hash

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true

Answer 1

如果需要链，您只需要第5步。（这与client-certificate chain in this question所描述的问题非常类似。）

最低要求是包括证书链，但排除，CA可以预期是远程方的信任锚（信任库）之一。如果您希望远程方信任发出证书本身的CA（根据您构建客户端信任库的方式确实如此），则不需要执行步骤5。毋庸置疑，如果您跳过第5步，您仍然需要使用证书文件（即长度为1的链）而不是连锁链文件的第6步。

例如：

假设你有： “根CA”发布的“服务器证书”

客户端具有“根CA”，或者没有。在这两种情况下，都没有必要发送“根CA”，因为它不会向客户端提供额外的信息。信任“根CA”的客户端将能够从“服务器证书”构建证书路径;客户端无论如何都不能完全信任该服务器证书。

假设你有：由“中间CA 1”颁发的“中间CA 1”颁发的“服务器证书”由“根CA”发布的“中级CA 2”

如果客户可以信任“中级CA 1”，只需出示“服务器证书”。

如果客户可以信任“中级CA 2”，则需要提供带有“Server Cert”和“Intermediate CA 1”的链。

如果客户可以信任“Root CA”，则需要提供带有“Server Cert”，“Intermediate CA 1”和“Intermediate CA 2”的链。

当然，示例1仅仅是示例2的特例。这就是为什么有些人不愿意使用“根CA”这一表达式：CA证书是否位于链的顶部并且是自签名的在构建信任链时几乎没有相关性。您所需要的只是远程方提前信任CA证书，该证书将能够验证您提供的链中的最后一个证书（该链是否长度为1或更长）。

Answer 2

在步骤5中，您只是将CA证书和服务器证书放入单个文件中，在步骤6中，您将两个证书都导入密钥库。导入最终实体证书（在您的案例中为服务器证书）时，AFAIK CA证书必须存在于密钥库中，以便验证最终实体证书的来源。

几天前，SO上有一个similar question：由于他缺少CA证书，因此将服务器证书导入密钥库时出现问题。他先导入CA然后一切正常。基于此，我认为步骤5是必要的，但您可以自己轻松尝试：只需跳过步骤5并尝试在步骤6中导入10.93.101.33.crt。

就准备密钥库的简单方法而言，如果您更喜欢基于GUI的工具，我建议您查看XCA进行CA管理，Portecle进行密钥库管理。

将本地CA签名的证书导入tomcat7 keystore.ks时，是否需要步骤5？

2 个答案: