Unable to switch to secure domain

Okay, I just read over your original post again. I’ll likely miss something else 'cos I’m really tired right now (it’s 4:30am here), but something that jumps out to me - if you indeed just installed Jitsi now, then you must be installing the latest stable. The last few stable versions of Jitsi have come with Lobby implemented out of the box, so you don’t have to configure it yourself. Which explains my first response to your issue (that I edited out): your cfg.lua file appears to be incomplete and incorrect. The lobby section seems to be missing and it looks like things are placed in the wrong blocks. For secure domain implementation, the position of the lobby block matters.

Clearly, this is not your full prosody config file. Post the full file to help make sense of the issue. You can edit out sensitive information like you did in the bit you posted.

You are right, but I did not change anything else. Only the two virtualhosts.
But I think there is something else wrong. There are a lot of java error in the jicofo.log.

Jicofo 2020-12-08 10:10:03.671 SEVERE: [17] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuild$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

And the I found a discussion on github [https://github.com/jitsi/jitsi-meet/issues/2117#issuecomment-366492454] about renewing the certificates. But doesnt help.

And a other discussion here https://community.jitsi.org/t/authentication-fails-with-prosody-0-11-2-but-works-with-0-9-12/17046/27

So, I set up a fresh clean debian “buster” host, run only the “Jitsi Meet Handbook” and did not change anything. I am able to setup a conference between an android mobile and a PC.
But there are a lot of errors in jicofo.log (like before)

Jicofo 2020-12-08 17:39:46.365 SCHWERWIEGEND: [16] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: host-unknown You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.ht$
<stream:error><host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text>This server does not serve auth.meeting.FQDN.com</text></stream:error>
org.jivesoftware.smack.XMPPException$StreamErrorException: host-unknown You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text>This server does not serve auth.meeting.FQDN.com</text></stream:error>
        at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1059)
        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)

&
jvb.log

2020-12-08 17:39:32.506 WARNUNG: [17] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#673: [MucClient id=shard hostname=localhost] error connecting
org.jivesoftware.smack.SmackException$ConnectionException: The following addresses failed: 'localhost:5222' failed because: localhost/127.0.0.1 exception: java.net.ConnectException: Verbindungsaufbau abgelehnt
(Connection refused), localhost/0:0:0:0:0:0:0:1 exception: java.net.ConnectException: Verbindungsaufbau abgelehnt (Connection refused)
        at org.jivesoftware.smack.SmackException$ConnectionException.from(SmackException.java:278)
        at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPConnection.java:619)
        at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:902)
        at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:383)
        at org.jitsi.xmpp.mucclient.MucClient.lambda$getConnectAndLoginCallable$7(MucClient.java:668)
        at org.jitsi.retry.RetryStrategy$TaskRunner.run(RetryStrategy.java:193)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

& prosody.log

Dec 08 17:39:54 jcp5561231a72b0 info    Incoming Jabber component connection
Dec 08 17:39:54 focus.meeting.FQDN.com:component       info    External component successfully authenticated
Dec 08 17:39:55 c2s556123193d10 info    Client disconnected: ssl handshake error: sslv3 alert certificate unknown
Dec 08 17:39:56 conference.meeting.FQDN.com:muc_domain_mapper  warn    Session filters applied
Dec 08 17:39:56 c2s5561231a9760 info    Client connected
Dec 08 17:39:56 c2s5561231a9760 info    Client disconnected: ssl handshake error: sslv3 alert certificate unknown
Dec 08 17:39:57 conference.meeting.FQDN.com:muc_domain_mapper  warn    Session filters applied
Dec 08 17:39:57 c2s556122fc5490 info    Client connected

When I add this to the configuration files:
…/jicofo/sip-communicator.properties
org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true

and
…/videobridge2/sip-communicator.properties
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true
then I am able to run a “secure” domain.

But what is the price, disabling the certificates?

The certificates uses by prosody for the xmpp connection to the jicofo and bridge are normally added to the trust store on the machine. Sometimes when you uninstall and install again those are not updated (there was a bug in one of the debian utilities about certs) and the newly generated ones are not added to that store.
With those settings you disable verifying those on the localhost connection.

But this time it is a fresh new debian buster server (from “netcup”) and an installation following the “Jitsi Meet Handbook”. And all certs I found are symbolic links to the same file or have the same content.
I know I miss something, but I didn’t found it yet. Maybe some rights…?

What is the java version?

I have the same problem, java 8 all done as written in quick install guide

I’m confused, as this is firewall issue or prosody not listening to that address.

This is another issue where prosody misses the config for that domain … can happen if prosody is configured after jicofo, which is normal for new installs and later when prosody is configured and restarted that is gone.

And the certs thing you mentioned, that @klaus1 changed is another problem. So 3 different problems are mentioned above.

Which one @orlovnv are you seeing?
And which java8? I saw people reporting that adoptopenjdk does not use the trust store from the machine.

this one


this is all what I have )))

So this is your problem. What we do is:

And apparently, that java version does not use /usr/local/share/ca-certificates/ and does not get the changes after updating those with update-ca-certificates -f.
Not sure what is the deal with adoptopenjdk and certs, if someone figures it out - any PRs are welcome.

Have a look at here Jicofo checkServerCerts unable to find valid certification path to requested target. Two things to check.

  1. Which java truststore jicofo and videobridge are looking in. You may need to add the following to JAVA_SYS_PROPS -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts.
  2. If the ca-certificates-java package is not currently installed then running update-ca-certificates will not have any effect on what is in /etc/ssl/certs/java.

`

as far as I understand, the current standard for java is storing the default trust store in
$JAVA_HOME/lib/security/cacerts
for Java 8 it’s almost the same but with a ‘jre’ subdirectory
$JAVA_HOME/jre/lib/security/cacerts
For Debian like OS, the standard is to have config under /etc, so cacerts is a symbolic link, and update-ca-certificates operates directly on the linked file.
However, adoptopenjdk is not making the cacerts a symbolic link, it’s a plain file. If another java is installed, a system one, the file under /etc will exist, and update-ca-certificates will find it and update it; however the adoptopenjdk java will not use the resulting file. Maybe removing the adoptopenjdk cacerts file and creating instead a symbolic link by hand, as is doing Ubuntu with its Java 8, could be a way ?

IMO the best way is to wipe adoptopenjdk and to use the normal system java, the 11 version. PPA are to be avoided when possible.

I don’t want to install a package from PPA too. Therefore I install the nvidia-openjdk-8-jre package from the official repo on Debian Buster for Jibri. It may work for JVB and Jicofo too.

apt-get install nvidia-openjdk-8-jre

mv /usr/lib/jvm/nvidia-java-8-openjdk-amd64/lib/security/cacerts \
    /usr/lib/jvm/nvidia-java-8-openjdk-amd64/lib/security/cacerts.bck
ln -sf /etc/ssl/certs/java/cacerts \
    /usr/lib/jvm/nvidia-java-8-openjdk-amd64/lib/security/

update-alternatives --install /usr/bin/java java \
    /usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java 50
update-alternatives --set java \
    /usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java

I don’t know if the nvidia-openjdk-8-jre package exists in the official Ubuntu repos

1 Like

I solve all my problems by install java 11, instead off recomended 8

Ubuntu is actually packaging Java 8, even on 20.04 LTS. Yes, it can sometimes appear that the Jitsi project is slightly biased toward Ubuntu.

After removing my jitsi installation, I did a new installation like before, but instead of installing “adoptopenjdk-8-hotspot

I installed

apt install default-jre

All certificates errors are gone, and even secure domain is up and running.
So for what we should install adoptopenjdk-8-hotspot

I can confirm the issue is with adoptjdk package not using the distro certificates store.

I configured the JVM as suggested by @emrah and it is working flawlessly now. I suggest updating the documentation in order not to suggest using that repository at all. I wasted hours trying to fix it, guessing it was a certificate/configuration issue.

But why not use the “default-jre”