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

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

我有一套工作步骤，可以创建keystore.ks，其链包括本地证书颁发机构证书。主tomcat（客户端）和从tomcat（服务器）之间的HTTPS通信工作；这很好，不过我担心我在slave keystore.ks中包含了太多内容

主tomcat（客户端）有一个truststore.ks，其中有一个条目，该条目是通过以下方式创建的：

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

2） 导入到truststore.ks

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

从属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

---

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

几天前这里有一个问题：guy在将服务器证书导入密钥库时遇到问题，因为他丢失了CA证书。他首先导入了CA，然后一切正常。基于此，我认为第5步是必要的，但您可以自己轻松地尝试：只需跳过第5步，尝试在第6步中导入10.93.101.33.crt

---

至于准备密钥库的更简单的方法是，如果您喜欢基于GUI的工具，我真的建议您检查CA管理和密钥库管理。

如果需要链，您只需要步骤5。（这是一个非常类似于为a描述的问题。）

最低要求是包括证书链，最多包括但不包括可以预期为远程方的信任锚（truststore）之一的CA。 如果您可以期望远程方信任颁发证书的CA本身（根据您构建客户机信任库的方式，确实是这样），则无需执行步骤5。不用说，如果跳过第5步，那么第6步仍然需要证书文件（即长度为1的链），而不是连接的链文件

例如：

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

客户机要么有“根CA”，要么没有。在这两种情况下，都没有必要发送“根CA”，因为它不会向客户端提供额外的信息。信任“根CA”的客户端将能够从“服务器证书”构建证书路径；一个客户机，如果不是简单地将无法信任该服务器证书无论如何

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

• 如果客户机可以信任“中间CA 1”，只需出示“服务器证书”
• 如果客户机可以信任“中间CA 2”，则需要提供一个包含“服务器证书”和“中间CA 1”的链
• 如果客户机可以信任“根CA”，则需要提供一个包含“服务器证书”、“中间CA 1”和“中间CA 2”的链

---

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

您链接到的问题是另一个问题，与其说是服务器提供的链，不如说是让客户机信任CA证书能够验证该链（在这个问题中只有长度1，因为没有中间CA）。实际上，您不需要发送链中远程方信任的CA证书：您只需要发送那些不信任的CA证书，希望其中一个证书将由远程方信任的CA之一颁发。我同意您的观点“您不需要发送链中远程方信任的CA证书”一般来说，如果跳过第5步，则在第6步中您会收到“keytool错误：java.lang.Exception:未能从reply建立链”，这与我链接的问题中描述的错误完全相同。此问题中没有引发错误的迹象。问题是在服务器提供的链中放置什么（在其密钥库中），而不是在客户端信任存储中放置什么（您对另一个问题的回答是关于什么的）。事实上，由于本例中没有中间证书，因此在服务器链中是否包含CA证书将不会有任何区别。当然，CA需要在客户端的信任库中（无论哪种方式）。在我的情况下，如果跳过第5步，则导致通信失败。嗨，Bruno。这是您几天前帮助解答的问题/答案的延续。在这种情况下，我使用XCA构建系统并使其正常工作。在这里，我只尝试使用命令行工具。我确实让它工作了，但是如果我不执行第5步，通信就会失败。我不吃了

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