将tomcat/hibernate配置为具有支持1.2.840.113549.1.5.13的加密提供程序 [英] configure tomcat/hibernate to have a cryptographic provider supporting 1.2.840.113549.1.5.13

问题描述

在配置具有jndi数据源的tomcat以使用ssl身份验证连接到Postgres服务器时(请参阅

While configuring a tomcat with a jndi datasource to connect using ssl authentication to a postgres server (see providing certificates to tomcat jndi connection to postgresql) I have the following error:

[main] WARN org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator - HHH000342: Could not obtain connection to query metadata : Cannot create PoolableConnectionFactory (Could not find a java cryptographic algorithm: Cannot find any provider supporting 1.2.840.113549.1.5.13.)

(这是初始化时间的警告，但是当我实际尝试使用连接时，我看到的错误与阻止访问数据库相同).

(this is a warning in initialization time, but when I actually try to use the connection, I see the same as an error preventing to access the database).

基于以下答案:在PEM中读取PKCS8格式:找不到提供程序我试图通过添加org.bouncycastle.jce.provider.BouncyCastleProvider作为第一个安全提供程序来修改/usr/lib/jvm/java-11-openjdk-amd64/conf/security/java.security.我还尝试将jar bcprov-jdk15on-1.64.jar添加到/usr/lib/jvm/java-11-openjdk-amd64/lib和/usr/share/java(在任何地方都没有lib/ext目录).

Based on this answer: Reading PKCS8 in PEM format: Cannot find provider I have tried to modify /usr/lib/jvm/java-11-openjdk-amd64/conf/security/java.security by adding org.bouncycastle.jce.provider.BouncyCastleProvider as the first security provider. I also tried to add the jar bcprov-jdk15on-1.64.jar to /usr/lib/jvm/java-11-openjdk-amd64/lib and /usr/share/java (there was no lib/ext directory anywhere).

问题仍然存在.

我应该如何告诉在Java运行时，tomcat或休眠状态下使用Bouncy Castle安全提供程序?

How should I tell to use the Bouncy Castle security provider either to the java runtime or tomcat or hibernate?

更新: 还尝试安装libbcprov-java并在java.security中设置安全提供程序，但没有成功.

Update: Also tried to install libbcprov-java and set the security provider in java.security, but no success.

推荐答案

我认为这是足够的答案信息，比注释更易读.而且更安全.

I think that's enough info for answer, which is more readable than comments. And safer.

SunJCE和bcprov都为多个PBES2系列密码(和PBKDF2作为组件)实现了Cipher实例，但由于名称或OID都没有为PBES2这样实现Cipher，因为PBES2不是一个密码，这是一个(大)家庭.如前所述，SunJCE确实通过OID和名称为PBES2实现了AlgorithmParameters. (当然，Bouncy在内部实现了PBES2参数，在我看来它们似乎可以在直接API或轻量级" API中使用，但不会通过提供者SPI公开这些参数.)

Both SunJCE and bcprov implement Cipher instances for several PBES2-family ciphers (and PBKDF2 as a component) but neither implements a Cipher for PBES2 as such, either by name or OID, because PBES2 is not one cipher, it is a (large) family of them. As I noted, SunJCE does implement AlgorithmParameters for PBES2 by both OID and name. (Bouncy of course implements PBES2 parameters internally, and it looks to me like they are usable in the direct or 'lightweight' API, but it does not expose them through the provider SPI.)

您的密钥文件 为PKCS8加密格式；问题在于PKCS8加密可以使用许多加密方案(密码)，包括不是由一个OID标识的PBES2系列(如PKCS5v1和PKCS12中的较旧/较简单的OBID)，而是由三个:外部" PBES2，PBKDF2(带有派生)参数)和基础对称密码(带有加密参数).

Your keyfile is in PKCS8 encrypted format; the issue is that PKCS8 encryption can use many encryption schemes (ciphers), including the PBES2 family which is not identified by one OID (like the older/simpler ones from PKCS5v1 and PKCS12) but three: 'outer' PBES2, PBKDF2 (with derivation params), and the underlying symmetric cipher (with encryption params).

假设 https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/ssl/LazyKeyManager.java 是正确的代码(行号205与您的stacktrace匹配) ，显然不是为了处理两层(PBES2)情况而设计的.但是，它确实尝试 未加密 PKCS8 首先，并且只有在失败的情况下，才尝试使用加密的PKCS8 由一个OID标识的方案.因此，如果您的环境中具有未加密的密钥文件是可以接受的，那应该行得通，我的建议也应该使用通过单级方案(例如PKCS12的pbeWithSHAAnd3-KeyTripleDES-CBC)加密的PKCS8-在检查后，我看到SunJCE实际上将其命名为PBEWithSHA1AndDESede，但使用正确的OID 1.2.840.113549.1.12.1.3，此处重要的是所有内容. (bcprov使用标准名称，但大写除外-JCA不区分大小写.)

Assuming https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/ssl/LazyKeyManager.java is the correct code (line number 205 does match your stacktrace), that obviously isn't designed to handle the two-level (PBES2) case. However, it does try unencrypted PKCS8 first, and only if that fails tries encrypted PKCS8 with a scheme identified by one OID. Thus if having an unencrypted keyfile in your environment is acceptable, that should work, and so should my suggestion of using PKCS8 encrypted with a single-level scheme like PKCS12's pbeWithSHAAnd3-KeyTripleDES-CBC -- which on checking I see SunJCE actually names PBEWithSHA1AndDESede but uses the correct OID 1.2.840.113549.1.12.1.3 which is all that matters here. (bcprov uses the standard name except in uppercase -- JCA is case-insensitive.)

根据创建密钥文件的软件或过程的不同，可能会对其进行调整以产生所需的格式.如果没有，并且您拥有或获得OpenSSL，它可以处理许多(大多数)PKCS8选项:

Depending on what software or process is creating your keyfile, it may be possible to adjust that to produce the desired format. If not, and you have or get OpenSSL, it can handle many (most) PKCS8 options:

# we need an intermediate PEM file; for safety (PB)encrypt it
openssl pkey <p8unusable.der -inform d -aes256 >temp.pem

# to unencrypted PKCS8
openssl pkcs8 -topk8 <temp.pem -outform d -nocrypt >p8unenc.der

# to encrypted PKCS8 using single-level PKCS12 scheme
openssl pkcs8 -topk8 <temp.pem -outform d -v1 pbeWithSHA1And3-KeyTripleDES-CBC >p8encone.der
# note OpenSSL spells SHA1 where PKCS12 had SHA (which was technically wrong)
# OTOH OpenSSL implies this is PKCS5v1 which it isn't. Bleah.

rm temp.pem # or erase or whatever

这篇关于将tomcat/hibernate配置为具有支持1.2.840.113549.1.5.13的加密提供程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！