javax.net.ssl.SSLProtocolException: The certificate chain length (11) exceeds the maximum allowed length (10)

Question

I'm struggling since my java MVC web application started throwing an exception when trying to create a WebService that has an specific https address (https://barramento.caixa.gov.br/sibar/ManutencaoCobrancaBancaria/Boleto/Externo?xsd=xsd0).

After enabling the javax.net.debug I figured out that the root cause of the problem seems to be the length of the certificate chain of the server application where I'm trying to connect to.

In a first moment, I suspected from the TLS version, but using nmap I was able to find the version of TLS the server is using as well as the ciphers, and they are not the problem. The server suports TLS1.1. I've already configured my server to work with this version, but it did not help at all.

I've searched all over the web for some information that could help but I was not able to find anything at Google pointing to nothing even close to "javax.net.ssl.SSLProtocolException: The certificate chain length".

Her is the stacktrace:

javax.net.ssl|FINE|26|http-nio-8080-exec-2|2020-11-06 17:30:36.178 BRT|Logger.java:765|READ: TLSv1.1 handshake, length = 3835
javax.net.ssl|SEVERE|26|http-nio-8080-exec-2|2020-11-06 17:30:36.188 BRT|Logger.java:765|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
"throwable" : {
  javax.net.ssl.SSLProtocolException: The certificate chain length (11) exceeds the maximum allowed length (10)
        at sun.security.ssl.CertificateMessage$T12CertificateMessage.<init>(CertificateMessage.java:143)
        at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:363)

Caused by: javax.net.ssl.SSLProtocolException: The certificate chain length (11) exceeds the maximum allowed length (10)
                at sun.security.ssl.CertificateMessage$T12CertificateMessage.<init>(CertificateMessage.java:143)
                at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:363)
                at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377)
                at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
                at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
                at sun.security.ssl.TransportContext.dispatch(TransportContext.java:182)
                at sun.security.ssl.SSLTransport.decode(SSLTransport.java:149)
                at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1143)
                at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1054)
                at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:394)

This post clarified a lot and gave me some guidance to understand the problem. But was not enought.

Note: the stranger thing is that this problem happens when running my application from an ubuntu instance using Java 1.8.0_272. When run my application from a Windows machine (also using Java 1.8.0_272) it doesn't happen.

Is there any JVM argument or any other way of set the lengh of the allowed certificate chain?

Has anyone already faced something like that?

Anchie

I've never heard of a certificate chain that long, and I've seen some long chains in the DoD. Do you have an 11 long chain, and why is it so long? – Gallonage

Actually this certificate is from a thirdy part server. I also don't know why it is that long. – Anchie

This is a new 'feature' in 8u271 and should apply to Windows as well -- is it possible your Windows machine is using a different Java than you think, or an HTTPS proxy, or reaching a different server? Although it appears the message and description are imprecise -- it is the number of certs in the message that is limited, not the chain; the message contains are supposed to be the chain, but in this case they are not. In any case, set the sysprop as described in the release notes. – Plaster

@PresidentJamesK.Polk+ the actual chain is only 4 (and can be reduced to 3 if you use modern Comodo roots). But that server (200.201.170.24) sends other irrelevant certs as well -- several of them expired -- and it is apparently the message not the actual chain that JSSE is (now) checking. ssllabs.com/ssltest/analyze.html?d=barramento.caixa.gov.br finds many other problems as well. – Plaster

Thank you very much @dave_thompson_085. This is exactly what I was looking for. Setting the jdk.tls.maxCertificateChainLength sysprop worked like a charm! – Anchie

Answer 1

As pointed by @dave_thompson_085, the actual chain is only 4. The problem was the many certificates sent by the server (also pointed by @dave_thompson_085).

Adding the "-Djdk.tls.maxCertificateChainLength=15" JVM argument solved the issue.

Thanks a lot @dave_thompson_085.

Anchie

The real solution is to fix the server. – Brake

Unfortunately, it is not an option. – Anchie