Unable to switch to secure domain

i have two jitsi server. The first i had setup in march this year and it works fine even with the new lobby. The second one I try to install now. Everything went fine until I switch to secure domain login.
When I start the room I get the message “waiting for host” and right after login as host I get again the Message “waiting for host”.
When I reload the page I am in the room, but not as host. When I rollback the “secure domain login” changes, everything is fine again.

It is a netcup hosted server with debian 10.
And the setup is done right out box of the following the “Jitsi Meet Handbook” with a nginx server and letsencrypt is installed with the jitsi script “install-letsencrypt-cert.sh”.

I added the line in “/etc/jitsi/jicofo/sip-communicator.properties”

Enabled the line in “/etc/jitsi/meet/FQDN-config.js”
anonymousdomain: 'guest.FQDN',

And the new VirtualHost in prosody

VirtualHost “FQDN”
– enabled = false – Remove this line to enable this host
authentication = “internal_plain”
– Assign this host a certificate for TLS, otherwise it would use the one
– set in the global section (if any).
– Note that old-style SSL on port 5223 only supports one certificate, and will always
– use the global one.
ssl = {
key = “/etc/prosody/certs/FQDN.key”;
certificate = “/etc/prosody/certs/FQDN.crt”;
speakerstats_component = “speakerstats.FQDN”
conference_duration_component = “conferenceduration.FQDN”
– we need bosh
modules_enabled = {
“ping”; – Enable mod_ping
– “muc_lobby_rooms”;
c2s_require_encryption = false
– lobby_muc = “lobby.FQDN”
– main_muc = “conference.FQDN”
– muc_lobby_whitelist = { “recorder.FQDN” } – Here we can whitelist jibri to enter lobby enabled rooms

VirtualHost "guest.FQDN"
        -- enabled = false -- Remove this line to enable this host
        authentication = "anonymous"
        modules_enabled = {
        c2s_require_encryption = false

Some ideas what went wrong?

Wait… my fault. You don’t have lobby enabled.
If I recall correctly, the configuration for secure domain in cfg.lua is:

VirtualHost “guest.my.domain.com
authentication = “anonymous”
c2s_require_encryption = false

The virtual host definition comes direct from the handbook.

Do you use STUN/TURN together with secure domain? If not, you have the wrong block.

I did not change anything else.
But when I remove the modules_enabled section in the “guest” host, nothing changed.

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)


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/ 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:

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
for Java 8 it’s almost the same but with a ‘jre’ subdirectory
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 \
ln -sf /etc/ssl/certs/java/cacerts \

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

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

1 Like