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

1 Like
Jitsi conference only works from locale network
#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.

1 Like
#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

1 Like
#5

Hi csett86,

Thhaannkkkssss! It works! But … why? I run Jitsi on one Server ( I think so because I haven’t set up an external Solution during Jitsi Setup). Do u think this problem occurs because “prosody” run an “untrusted” localhost Connection who is not registered in Javas “jssecacerts”?
And is this method safe. I mean u said that:

if prosody, jicofo and jvb are on the same host anyway and you don’t need the ssl verification for security reasons

What did that mean? Did this setting are only affected in local environment?

#6

Jitsi installer is a Debian installer and as such it follows the Debian conventions on the certificates location.
Java has its own convention that is different, but Java as packaged by Debian distribution follows both conventions with the magic of symbolic links.
A Java that is not packaged by Debian people will not necessarily follow this practice and the Jitsi Java components (Jicofo, Jvb) will not be able to connect to Prosody because the Prosody certificates will not be trusted by Java.
A solution is to instruct Jitsi components to trust any certificates whatever they are.
Another solution is to create the symbolic links yourself for the Java you use.
If you use all components on a single computer there is not much possibility for an evil Prosody server to allow itself to be connected by your innocent Jicofo and Jvb instead of your true Prosody server and steal all their money so it does not matter too much.

1 Like
Jitsi conference only works from locale network
#7

Hi @gpatel-fr ,
thank you very much for your reply. From now, I am a bit smarter :wink: I think my problem Jitsi conference only works from locale network is now completely solved.

Have a good day,
Leon

#8

Helllo i followed this way but still not working ,how can i fix this ,is there any way ,please help me ,i am onyo this issue from 10 days