AWS Corretto Java: unable to find valid certification path

Install & Config
#1

AWS has a version 8 of their java jdk, Corretto. Corretto is interesting for jitsi, especially the videobridge, since it has asm/C crypto routines (which run only on linux). AWS claims ~25% improvements for crypto heavy users, such as videobridge. https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/

I’m on a stock ubuntu 20.04 instance. I installed corretto.
java -version
openjdk version “1.8.0_252”
OpenJDK Runtime Environment Corretto-8.252.09.1 (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM Corretto-8.252.09.1 (build 25.252-b09, mixed mode)

Both jicofo and jvb are very unhappy:

020-06-13 13:03:55.982 WARNING: [535] org.jivesoftware.smack.AbstractXMPPConnection.callConnectionClosedOnErrorListener: Connection XMPPTCPConnection[
not-authenticated] (0) closed with error
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBu
ilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1967)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:331)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:1010)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1079)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1388)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1416)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1400)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnection.java:810)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1200(XMPPTCPConnection.java:151)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1071)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:450)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:317)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1670)
… 13 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:445)
… 19 more

Both Oracle and AWS CA’s should be there, I didn’t remove openjdk. And this is a stock AWS image.

With openjdk, no problem. and I can just remove Corretto and reboot. No problem. So try it yourself.

I figure there must be some java option I need to provide. Or does the letsencrypt script only work with openjdk ?

#2

The problem with this for me was always the self-signed “auth” certificate that the jitsi prosody config is using. Probably your new jvm does not use the system cacerts where the prosody “auth” certificate is added (from /var/lib/prosody/auth.meet.example.org.crt). You can disable certificate check in jicofo and jvb as an easy workround (if prosody, jicofo and jvb are on the same host anyway and you don’t need the ssl verification for security reasons).

For JVB: add in /etc/jitsi/videobridge/sip-communicator.properties

org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

For Jicofo: add in /etc/jitsi/jicofo/sip-communicator.properties

org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true

#3

I owe you a beer. Worked like a charm. And yes, everything is on the same instance.

I seems Corretto creates its own truststore, and doesn’t use/supplement the system truststore.
See:


With your suggestion, it won’t affect me since I’m only on one instance. But for any of the grand designs involving multiple jvb’s across worldwide AWS regions, Corretto may be a non-starter. Odd they won’t solve it.

#4

Now as everythings running I am very interested in benchmarks with the new JCE / crypto provider. Maybe a flame graph helps comparing as described in this thread: Server load for many simultaneous meetings