将Local CA签署的证书导入到Tomcat7 KeyStore.ks时，我是否需要步骤5

Question

我希望您的帮助确定为什么需要步骤5（接近末端）。

我有一组工作的步骤，可以创建一个带有链条的KeyStore.ks，其中包括本地证书授权证书。HTTPS主猫（客户端）和从属tomcat（服务器）工作之间的HTTPS通信；这很棒，除了我担心我在奴隶密钥库中包括很多。

主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

从属tomcat（服务器）具有一个键库。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。（这与此问题中客户认证链所描述的问题非常相似。）

最少的要求是包括最多的证书链，但不包括，可以预期的CA是远程方的信托锚（TrustStore）之一。如果您可以期望远程方信任发布证书本身的CA（实际上是根据您构建客户端信托店的方式），则不需要步骤5。不用说，如果跳过步骤5，您仍然需要使用证书文件（即长度1）而不是串联链文件的步骤6。

例如：

1. 假设您有：" root ca"

   发行的"服务器证书"

   客户端具有" root ca"，或者没有。在这两种情况下，发送" root ca"毫无意义，因为它不会向客户提供其他信息。信任" root ca"的客户端将能够从"服务器证书"构建证书路径；一个不根本无法信任该服务器证书的客户端。

2. 假设您有：发行的"服务器证书" "中间CA 1" 由" Intermediate Ca 2"发行，由" root ca" 发行

   • 如果可以期望客户信任"中间CA 1"，则只是呈现"服务器证书"。
   • 如果可以期望客户信任"中间CA 2"，则需要提供一个带有"服务器证书"one_answers"中间CA 1"的链条。
   • 如果可以期望客户信任" root ca"，则需要使用"服务器证书"，"中级CA 1"one_answers"中级CA 2"呈现链条。

当然，示例1只是示例2的特殊情况2。这就是为什么有些人不愿意使用" root ca"一词：CA证书是否位于链的顶部并且是自我签名的在构建信任链时几乎没有相关。您所需要的只是远程政党要提前信任CA证书，该证书将能够验证您提出的链条中的最后证书（无论该链的长度为1或更多）。

Answer 2

在步骤5中，您只是将CA证书和服务器证书放入一个文件中，在步骤6中，您将两个证书导入了密钥库。当您导入最终实体证书（在您的情况下使用服务器证书）时，AFAIK CA证书必须存在于密钥库中。

几天前，这里有一个类似的问题：盖伊在钥匙店里导入服务器证书的问题，因为他缺少CA证书。他先进口了CA，然后一切都起作用。基于此，我认为步骤5是必要的，但您可以轻松地自己尝试：只需跳过步骤5并尝试导入10.93.101.33.crt在步骤6中。

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