Correcting certificate paths

Hello

I’ve just installed jitsi-meet on Debian buster. I had already created a LetsEncrypt cert for my subdomain. I selected “I want to install my own certificate” and entered the paths for key and cert. Unfortunately I entered fullchain.pem for both. I should have entered privkey.pem for the key path.

I then set up prosody authorisation according to the secure domain document.

When I go to the URL, I get the Jitsi Meet page with meeting name and Start Meeting button. I don’t get any prompt to join as the user with the right to start a meeting, and if I click on Start Meeting I get the “You have been disconnected” loop. I can post the browser console error log if needed.

I’d like to reconfigure the relevant Jitsi components and re-enter the correct private key path. I tried dpkg-reconfigure jitsi-meet-web-config
but that just lets me accept “I want to install my own certificate” again and tells me to execute /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh.

That script looks like it will create a new LetsEncrypt certificate, and also crontabs a renew job. I already have the certificate and a different cron job that renews all my certs.

I ran apt reinstall jitsi-meet but it didn’t give me a config dialogue.

I ran dpkg-reconfigure jitsi-meet and it returned with no output.

I could extract and run the relevant parts of install-letsencrypt-cert.sh but that might be dangerous. Is there a correct way to reconfigure certificate paths?

Which java do you use adoptjdk has a bug and don’t use system trusted certs and prevent jicofo from connecting prosody.
Reconfigure is not very well tested, you better uninstall using the command from the handbook and try again

Yes I used adoptjdk as OpenJDK 8 is not part of the Debian buster packages. That’s an extra source of errors then, but I know that the current config is broken and won’t work until it’s fixed.

Yes I’ll uninstall and start from the beginning, and will let you know if it fixes it.

I did that, and entered the paths to privkey.pem and fullchain.pem during jitsi-meet install. I didn’t do the secure domain changes so that I test one thing at a time. Same problem, I get the you have been disconnected loop.

Start of the stack trace in /var/log/jitsi/jicofo.log:

Jicofo 2021-02-06 19:22:49.241 INFO: [1] org.eclipse.jetty.server.Server.doStart() jetty-9.4.35.v20201120; built: 2020-11-20T21:17:03.964Z;
git: bdc54f03a5e0a7e280fab27f55c3c75ee8da89fb; jvm 1.8.0_282-b08
Jicofo 2021-02-06 19:22:49.553 SEVERE: [16] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
org.jivesoftware.smack.SmackException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1076)
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: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654)
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
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)
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)
… 3 more

Am I correct to use my LetsEncrypt privkey.pem and fullchain.pem for the key and cert paths?

Why is Jetty mentioned? I run Apache and I thought Jetty wasn’t needed. I don’t even think it’s installed!

Thanks in advance

Jetty is internally used by jicofo and jvb. You are still hitting the problem with the certs of adoptjdk.

Thanks.

Does that mean that it’s impossible to install and run a Jitsi server under the latest Debian version?

I have just moved my server hosting from one with a very old Debian, mainly so I could run Jitsi on it!

Well, is there java11 there? That should be fine. I will try next week to test it and update guides

Yes, the adoptopen repository includes the 11 versions. So I removed adoptopenjdk-8-hotspot. That also removed jicofo jitsi-meet and jitsi-videobridge2 but not their config, so after installing adoptopenjdk-11-hotspot I reinstalled them. (Should I have run apt-get update first?)

No improvement. The jicofo.log seems the same.

Is it possible that I have something else wrong? Is there any way I can test the certificates and check the config? Is is possible that jicofo etc can’t read the private key?

I didn’t set the hostname or FQDN, but that is marked as optional. Anyway I can’t see that this is possible on a server that does other things beside Jitsi.

Hello @grepnoid,

You can try jitsi-buster-installer or compare its code with your installation steps

Thank you emrah. I’ve noticed that the key and cert prosody stores for meet.mydomain.com is still not the Letsencrypt one I created manually!

I want to keep to the simplest install as in https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart. I don’t want to use TURN/STUN which the docs say is optional. I don’t want to set the FQDN stuff, and certainly not change my hostname and risk breaking other things already on my server. Also, if the simple instructions are wrong it might help with the forthcoming rewrite.

So I’ll try once more with a complete uninstall, and manually search for and remove anything left. Maybe I should do the steps here which looks like it fixes adoptjdk 8. Or use 11.

On further reflection, as this is not urgent, I think I’ll wait a few weeks and try again then. Damencho has said he’s going to test adoptjdk 11 so things might be more stable for Debian buster users then.

Thanks to all.

Yes this seems to be the same issue we observed in the other thread. I am running Jitsi on Buster with AdoptOpenJdk 8 and the fixes described in that other thread and it’s fine now.

Isn’t there something other than adoptjdk? That seems broken, I wanted to check the standard openjdk which works everywhere and just edit the docs and note to not use adoptjdk …

That’s good news. But still doesn’t explain why there’s a cert and key for meet.mydomain.com which isn’t the one I created, though I never requested a self-signed one. I must fix that first.

There is a standard openjdk in buster, but it’s openjdk-11. If I had an otherwise clean and working jitsi install I’d try it, but if you can test that that package will work here I’m sure it will help a lot of people.

Prosody needs certificates to operate even selfsigned ones work. The interaction between the rest of the components and prosody is done in two locations, one is the bosh/websocket endpoint which is done on localhost and http no cert is used. The other one is port 5222by jicofo, where we have added that cert to the trusted certs on local machine and where adoptjdk shits the bed :slight_smile:
You only need publicly trusted certificate in nginx and turnserver as those are the two endpoints facing the public Internet and clients.

That’s my plan, will do it probably on Monday

In fact openjdk 11 to 17 are standard packages. I’ll wait for your results and try again after a complete uninstall and purge.

I just did the test and on a clean Debian buster using the following commands worked with no problem:

apt install apt-transport-https curl gpg
curl https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo 'deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list > /dev/null
apt update
apt install jitsi-meet
/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
# java -version
openjdk version "11.0.9.1" 2020-11-04
OpenJDK Runtime Environment (build 11.0.9.1+1-post-Debian-1deb10u2)

I will soon edit the handbook.

1 Like

Did your clean Debian buster include openjdk-11? Mine didn’t so I’ll install it after a remove and purge of all jitsi components and dependencies.

In the jitsi installation debconf, did you say you had your own certs and enter the cert paths? Knowing that you’d be creating them there later?

I can’t decide whether to run install-letsencrypt-cert.sh and get a new cert, as the existing one isn’t used anywhere else. Or to keep the existing ones, which will test that it gets used by jicofo/prosody etc. I don’t know what the sed commands in install-letsencrypt-cert.sh do, but I hope they aren’t necessary.

I see that install-letsencrypt-cert.sh creates the certs in the default LetsEncrypt place and doesn’t change owner group or permissions. Can jicofo and prosody read it as root?