TLSv1.3 is relatively new and shiny, as fundamental web protocols go, and TLS stacks are still working out the bugs. In my experience:
https://jira.atlassian.com/browse/JRASERVER-70780
https://jira.atlassian.com/browse/JRASERVER-70189
This was triggered by some change on Slack's end. Perhaps Slack switched their default from TLS 1.2 to 1.3 when they removed older TLS versions the previous month.
Same client, 4 months later, suddenly experienced complete failure of Crowd to authenticate users against their LDAP.
The relevant line in the stacktrace is:
Caused by: org.springframework.ldap.CommunicationException: ldap.phx7.<redacted>.com:636; nested exception is javax.naming.CommunicationException: ldap.phx7.<redacted>.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: extension (5) should not be presented in certificate_request] |
Once again some hurried Googling suggested this is a TLSv1.3 problem.
In both cases the solution was to avoid TLSv1.3 for now, by setting the Java flag:
-Djdk.tls.client.protocols=TLSv1.2 |
The first bug might also be avoidable by upgrading to Java 11.0.8 or higher. I haven't tested that yet though.
For now, I'm setting that flag in all instances I administer, until TLS servers and clients get their act together.