Please mention all BC jar versions as well as the Java runtime version. It's not possible to completely replicate the checks outside of the TLS context, but we can infer that theTrustManager configuration is the underlying issue.

A BCJSSESSLContext should ideally be used with a BCJSSETrustManagerFactory (and therefore its own trust managers). Simple exceptions should be OK if they wrap an underlying BCJSSE trust manager and don't interfere with the main behaviour (e.g. a logging wrapper would be OK).

If a BCJSSESSLContext is initialized with a non-BCJSSETrustManager, then it will get a wrapper; eitherImportX509TrustManager_5 orImportX509TrustManager_7 depending on whether the non-BCJSSETrustManager implementsX509ExtendedTrustManager.

X509ExtendedTrustManager was added in Java 7 and there are some checks that can only be performed by a trust manager that gets the extra parameters available inX509ExtendedTrustManager calls. If only theX509TrustManager API is available then some supplemental checks are performed on a best effort basis.

That is the situation here as indicated byImportX509TrustManager_5 in the stack trace, which has already called the underlyingX509TrustManager and is now trying to check algorithm constraints as best it can. The signature algorithm of a trusted cert (TA) is not subject to algorithm constraints checks, but that relies ongetAcceptedIssuers (from the underlyingX509TrustManager) to try and learn the set of trusted certificates. I presume that is going wrong in some way here.

It would help if you couldset a breakpoint inX509TrustManagerUtil.importX509TrustManager and investigate thex509TrustManager argument to that method to see its type, whether it is a wrapper for another trust manager, etc. I'm not familiar with Keycloak, but it' s not uncommon for JSSE-using software to inject custom wrappers for key/trust managers, and these are usually only tested with SunJSSE and are often obsolete workarounds in any case.

EDIT: One more thing; based on the title and other hints, possibly you are adding your chain in the wrong order for JSSE. The "right" order is the reverse of their appearance in the Sectigo-Chain.txt file.

Here are the versions of the BC jars, straight from my Dockerfile

RUN curl -ksSL https://downloads.bouncycastle.org/fips-java/bc-fips-1.0.2.5.jar > /tmp/bc-fips-1.0.2.5.jarRUN curl -ksSL https://downloads.bouncycastle.org/fips-java/bctls-fips-1.0.19.jar > /tmp/bctls-fips-1.0.19.jarRUN curl -ksSL https://downloads.bouncycastle.org/fips-java/bcpkix-fips-1.0.7.jar > /tmp/bcpkix-fips-1.0.7.jar

Keycloak 26.1.0 comes with OpenJDK version 21.
I will reverse the order in the CA chain and see if the issue still persists.

I've updated the certificate chain to reverse the order but I'm still facing the same issue. Attached is the updated certificate chain.
Sectigo-Chain.txt Unfortunately I don't have the ability or cycles to debug the TrustManager. I will create an issue in the Keycloak repo in an effort to find the root cause.

Are you sure it'sexactly the same exception? If you reversed the chain I would guess the exception message shortened to just "Signature algorithm 'SHA1WITHRSA' not permitted with given parameters". That would confirm that the code was unable to determine the trusted certs per my guess above.

You are correct. The message was shortened.

Caused by: java.security.cert.CertPathValidatorException: Signature algorithm 'SHA1WITHRSA' not permitted with given parametersat org.bouncycastle.jsse.provider.ProvAlgorithmChecker.checkIssued(ProvAlgorithmChecker.java:262)at org.bouncycastle.jsse.provider.ProvAlgorithmChecker.checkChain(ProvAlgorithmChecker.java:205)at org.bouncycastle.jsse.provider.ImportX509TrustManager_5.checkAlgorithmConstraints(ImportX509TrustManager_5.java:106)... 33 more

Attached is the entire log file.
sha1withrsa-error.txt

@ghettosamson It occurs to me that you shouldn't be including the SHA1withRSA root certificate in the chain that you deployed to postgres (just remove it from that chain). It is unnecessary (and unusual) in TLS to have the root cert in the sent chain because any TLS peer would have to already have the root certificate (or some intermediate CA) in a trust store somewhere to be able to verify the chain anyway. (There is a special case when a single self-signed certificate IS the chain).

To be clear, the BCJSSE TrustManager could tolerate it being there but not when it has to work with the third-party wrapper that doesn't support X509ExtendedTrustManager.