Java JDBC&x2B;SSL:将CA证书、客户端证书和客户端绑定到单个密钥库文件中

Java JDBC&x2B;SSL:将CA证书、客户端证书和客户端绑定到单个密钥库文件中,java,mysql,ssl,jdbc,keytool,Java,Mysql,Ssl,Jdbc,Keytool,Google Cloud SQL通过为您生成服务器ca-cert.pem、客户端-cert.pem和客户端密钥.pem来支持SSL连接。通过以下步骤,我成功地将Java客户端连接到云SQL: 1) 将服务器CA证书导入信任库文件: keytool -import -alias mysqlServerCACert -file ca-cert.pem -keystore truststore keytool -importkeystore -deststorepass keystore -dest

Google Cloud SQL通过为您生成服务器
ca-cert.pem
、客户端-cert.pem和客户端密钥.pem来支持SSL连接。通过以下步骤,我成功地将Java客户端连接到云SQL:

1) 将服务器CA证书导入信任库文件:

keytool -import -alias mysqlServerCACert -file ca-cert.pem -keystore truststore
keytool -importkeystore -deststorepass keystore -destkeystore keystore -srckeystore client.p12 -srcstoretype PKCS12 -srcstorepass keystore -alias clientalias
2) 将客户端证书和客户端密钥捆绑到pkcs12文件中:

openssl pkcs12 -export -in client-cert.pem -inkey client-key.pem -out client.p12 -name clientalias -CAfile ca-cert.pem
3) 将pkcs12导入密钥库文件:

keytool -import -alias mysqlServerCACert -file ca-cert.pem -keystore truststore
keytool -importkeystore -deststorepass keystore -destkeystore keystore -srckeystore client.p12 -srcstoretype PKCS12 -srcstorepass keystore -alias clientalias
4) 告诉JVM使用我的信任库和密钥库:

-Djavax.net.ssl.keyStore=/path/to/my/keystore \
-Djavax.net.ssl.keyStorePassword=keystore \
-Djavax.net.ssl.trustStore=/path/to/my/truststore \
-Djavax.net.ssl.trustStorePassword=truststore
这一切都是可行的,但不幸的是,它排除了来自其他客户端库的出站HTTPS连接——在我的例子中是Firebase java客户端库。问题是我的
-Djavax.net.ssl.trustStore
参数已经覆盖了与JDK绑定的默认
cacerts
文件

我似乎有两个选择。一种不理想的选择是,在每台生产和开发机器上,使用特定于操作系统和JDK版本的命令,将我的服务器CA证书导入JDK的
cacerts
文件。对于实际的生产设置,此选项似乎不太方便

另一个选项是将我的服务器CA证书和客户端证书捆绑到一个(本地)信任链中,然后Java将使用该信任链验证我的客户端密钥。从我所读到的,我很确定这是可能的,但我不知道所需的咒语

我的猜测是,我应该使用一个
openssl
命令以正确的顺序创建一个包含我的服务器CA证书、客户端证书和客户端密钥的pkcs12包,然后使用
keytool
将其导入一个新的密钥库。我将省略
-D../trustStore
JVM参数,只指定密钥库参数。Java将使用本地CA信任链作为我的云SQL客户端密钥,但对于所有其他SSL协商,它将退回到全局
cacerts
文件


这可能吗?如果不能直接作为单个pkcs12实现,那么是否有其他一些步骤可以将它们全部放入一个密钥库中,从而绕过信任库的需要?

将默认JRE
cacerts
文件复制到新的信任库中,并将服务器证书添加到该信任库中。用于所有客户端。将此作为构建步骤,并在每次升级JRE时重复,这样您就不会错过默认
cacerts中的证书更改。


当然,如果服务器证书由可识别的CA正确签名,则无需将其导入任何位置或使用自定义信任库。如果它不是由公认的CA签名的,它应该是。

有趣的想法。如果没有其他办法的话,我肯定会用这个作为备用方案。我还将与云SQL团队讨论如何正确签署他们的证书。今天我与一名安全人员进行了交谈,他提出了同样的建议。接受你的答案。更新:这个解决方案对我很有效,而且非常简单。再次感谢!