Sectigo Certificate chain rejected because End entity was signed with SHA1withRSA but my certificate was signed with sha256WithRSAEncryption

[ghettosamson]

Versions: Keycloak 26.1.0 in Docker and Postgres 16.6-alpine3.20. I am using BouncyCastle for my Keycloak in FIPS mode. My expiring certificate was signed by Entrust and I did not experience this issue. I have a new certificate signed by Sectigo with sha256WithRSAEncryption. I deploy my Postgres with my private key and certificate with chain. When I start my keycloak container and it attempts to connect to Postgres, I get the following error.

2025-02-14 17:18:40,576 INFO  [org.bouncycastle.jsse.provider.ProvTlsClient] (agroal-11) [client #2 @65a7da3b] raised fatal(2) certificate_unknown(46) alert: Failed to read record: org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
	at org.bouncycastle.jsse.provider.ProvSSLSocketWrap.checkServerTrusted(ProvSSLSocketWrap.java:131)
	at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(ProvTlsClient.java:382)
	at org.bouncycastle.tls.TlsUtils.processServerCertificate(TlsUtils.java:4827)
	at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(TlsClientProtocol.java:797)
	at org.bouncycastle.tls.TlsClientProtocol.receive13ServerCertificate(TlsClientProtocol.java:1596)
	at org.bouncycastle.tls.TlsClientProtocol.handle13HandshakeMessage(TlsClientProtocol.java:160)
	at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:366)
	at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:715)
	at org.bouncycastle.tls.TlsProtocol.processRecord(TlsProtocol.java:591)
	at org.bouncycastle.tls.RecordStream.readRecord(RecordStream.java:247)
	at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:879)
	at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:427)
	at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:88)
	at org.bouncycastle.jsse.provider.ProvSSLSocketWrap.startHandshake(ProvSSLSocketWrap.java:607)
	at org.bouncycastle.jsse.provider.ProvSSLSocketWrap.startHandshake(ProvSSLSocketWrap.java:583)
	at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:51)
	at org.postgresql.core.v3.ConnectionFactoryImpl.enableSSL(ConnectionFactoryImpl.java:638)
	at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:201)
	at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:268)
	at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:54)
	at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:273)
	at org.postgresql.Driver.makeConnection(Driver.java:446)
	at org.postgresql.Driver.connect(Driver.java:298)
	at io.agroal.pool.ConnectionFactory.createConnection(ConnectionFactory.java:225)
	at io.agroal.pool.ConnectionPool$CreateConnectionTask.call(ConnectionPool.java:580)
	at io.agroal.pool.ConnectionPool$CreateConnectionTask.call(ConnectionPool.java:561)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at io.agroal.pool.util.PriorityScheduledExecutor.beforeExecute(PriorityScheduledExecutor.java:75)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.security.cert.CertPathValidatorException: Signature algorithm 'SHA1WITHRSA' not permitted with given parameters and issuer public key
	at org.bouncycastle.jsse.provider.ProvAlgorithmChecker.checkIssuedBy(ProvAlgorithmChecker.java:281)
	at org.bouncycastle.jsse.provider.ProvAlgorithmChecker.check(ProvAlgorithmChecker.java:163)
	at org.bouncycastle.jsse.provider.ProvAlgorithmChecker.checkChain(ProvAlgorithmChecker.java:213)
	at org.bouncycastle.jsse.provider.ImportX509TrustManager_5.checkAlgorithmConstraints(ImportX509TrustManager_5.java:106)

Attached find the Sectigo certificate chain.
Sectigo-Chain.txt

Is this a bug? If not, is there a way to tell BC to allow this? I've tried several things like removing the chain from the certificate, but Keycloak then complains that the certificate needs the chain. The way I am specifying the private key and the certificate in Keycloak is via the following environment variables, KC_HTTPS_CERTIFICATE_KEY_FILE and KC_HTTPS_CERTIFICATE_FILE and thats all I am providing. I also tried adding KC_TRUSTSTORE_PATHS but that didn't help.

[peterdettman]

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 the TrustManager configuration is the underlying issue.

A BCJSSE SSLContext should ideally be used with a BCJSSE TrustManagerFactory (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 BCJSSE SSLContext is initialized with a non-BCJSSE TrustManager, then it will get a wrapper; either ImportX509TrustManager_5 or ImportX509TrustManager_7 depending on whether the non-BCJSSE TrustManager implements X509ExtendedTrustManager.

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 in X509ExtendedTrustManager calls. If only the X509TrustManager API is available then some supplemental checks are performed on a best effort basis.

That is the situation here as indicated by ImportX509TrustManager_5 in the stack trace, which has already called the underlying X509TrustManager 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 on getAcceptedIssuers (from the underlying X509TrustManager) to try and learn the set of trusted certificates. I presume that is going wrong in some way here.

It would help if you could set a breakpoint in X509TrustManagerUtil.importX509TrustManager and investigate the x509TrustManager 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.

[ghettosamson]

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.jar
RUN curl -ksSL https://downloads.bouncycastle.org/fips-java/bctls-fips-1.0.19.jar > /tmp/bctls-fips-1.0.19.jar
RUN 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.

[ghettosamson]

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.

[peterdettman]

Are you sure it's exactly 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.

[ghettosamson]

You are correct. The message was shortened.

Caused by: java.security.cert.CertPathValidatorException: Signature algorithm 'SHA1WITHRSA' not permitted with given parameters
	at 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

[peterdettman]

@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.