Я думаю, что для ответа достаточно информации, которая более читаема, чем комментарии. И безопаснее.
И SunJCE, и bcprov реализуют экземпляры Cipher для нескольких шифров семейства PBES2 (и PBKDF2 в качестве компонента), но ни один не реализует Cipher для PBES2 как такового, либо по имени, либо по OID, поскольку PBES2 не являетсяодин шифр, это (большая) семья из них. Как я уже отметил, SunJCE реализует AlgorithmParameters для PBES2 как по OID, так и по имени. (Конечно, Bouncy реализует внутренние параметры PBES2, и мне кажется, что они могут использоваться в прямом или «легковесном» API, но он не предоставляет их через SPI провайдера.)
Ваш ключевой файл в зашифрованном формате PKCS8;проблема заключается в том, что в шифровании PKCS8 могут использоваться многие схемы шифрования (шифры), в том числе семейство PBES2, которое не идентифицируется одним OID (как старые / более простые из PKCS5v1 и PKCS12), а тремя: «внешним» PBES2, PBKDF2 (с деривацией). params) и базовый симметричный шифр (с параметрами шифрования).
Предполагая, что https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/ssl/LazyKeyManager.java является правильным кодом (номер строки 205 соответствует вашей трассировке стека), который явно не предназначен для обработки двухуровневого (PBES2) случая. Тем не менее, он делает попытку в незашифрованном виде PKCS8 в первую очередь, и только в случае неудачи пытается шифрование PKCS8 со схемой, идентифицируемой одним OID. Таким образом, если наличие незашифрованного ключевого файла в вашей среде приемлемо, это должно сработать, и поэтому мое предложение об использовании PKCS8, зашифрованного с помощью одноуровневой схемы, такой как pbeWithSHAAnd3-KeyTripleDES-CBC PKCS12, - при проверке которой я вижу SunJCE, фактически называет PBEWithSHA1AndDESede, ноиспользует правильный OID 1.2.840.113549.1.12.1.3, и это все, что здесь имеет значение. (bcprov использует стандартное имя, за исключением заглавных букв - в JCA регистр не учитывается.)
В зависимости от того, какое программное обеспечение или процесс создает ваш ключевой файл, может быть возможно настроить его для получения желаемого формата. Если нет, и вы имеете или получаете OpenSSL, он может обрабатывать многие (большинство) параметров PKCS8:
# 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