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

Question

我需要你的帮助来确定为什么第 5 步(接近尾声)是必要的。

我有一组有效的步骤来创建一个 keystore.ks，其中包含一个包含本地证书颁发机构证书的链。主tomcat(客户端)和从tomcat(服务器)之间的HTTPS通信工作；这很好，除了我担心我在从属 keystore.ks 中包含太多内容。

主 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(服务器)有一个 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) 使用完整的证书链更新 keystore

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

以上步骤确实创建了一个工作系统。客户端 tomcat 可以通过 https 与服务器 tomcat 通信，而不会出现信任问题。我关心几件事，为什么我需要将 CA 证书添加到服务器 tomcat 的 keystore 中？最后，有没有更简单的方法来做到这一点？

感谢您的宝贵时间。

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

完整的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 所描述的问题非常相似。)

最低要求是包括证书链，但不包括可以预期成为远程方信任 anchor (信任库)之一的 CA。 如果您可以期望远程方信任自己颁发证书的 CA(根据您构建客户端信任库的方式，情况确实如此)，则不需要第 5 步。不用说，如果您跳过第 5 步，您仍然需要使用证书文件(即长度为 1 的链)而不是串联的链文件进行第 6 步。

例如:

1. 假设您有: “服务器证书”由“根 CA”颁发

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

2. 假设您有: “服务器证书”由颁发“中间 CA 1”由“中间 CA 2”由“根 CA”颁发

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

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