Authentication required


#1

Hello,

I had a hard time configuring jitsi.

Unfortunately I’m facing a new challenge, when I open a chatroom I’m asked an authentication.

user@domain.net
password

I tried to enter an email + password that I know to work

I extracted this error

Nov 06 19:19:30 stanzarouter debug Routing to remote…
Nov 06 19:19:30 mod_s2s debug opening a new outgoing connection for this stanza
Nov 06 19:19:30 mod_s2s debug stanza [iq] queued until connection complete
Nov 06 19:19:30 mod_s2s debug First attempt to connect to focus.mydomain.org, starting with SRV lookup…
Nov 06 19:19:30 adns debug Records for _xmpp-server._tcp.focus.mydomain.org. not in cache, sending query (thread: 0x2c4807a3a00)…
Nov 06 19:19:30 adns debug Sending DNS query to 10.255.89.254
Nov 06 19:19:30 mod_bosh debug We have an open request, so sending on that
Nov 06 19:19:30 mod_bosh debug Request destroyed: table: 0x2c45f77c100
Nov 06 19:19:30 bosh53d16e78-6230-45e0-8afd-a054d2866879 debug BOSH session marked as inactive (for 60s)
Nov 06 19:19:30 socket debug server.lua: closed client handler and removed socket from list
Nov 06 19:19:30 mod_bosh debug Session 53d16e78-6230-45e0-8afd-a054d2866879 has 0 out of 1 requests open
Nov 06 19:19:30 mod_bosh debug and there are 0 things in the send_buffer:
Nov 06 19:19:30 socket debug server.lua: closed client handler and removed socket from list
Nov 06 19:19:30 adns debug Reply for _xmpp-server._tcp.focus.mydomain.org. (thread: 0x2c4807a3a00)
Nov 06 19:19:30 mod_s2s debug focus.mydomain.org has no SRV records, falling back to A/AAAA
Nov 06 19:19:30 adns debug Records for focus.mydomain.org not in cache, sending query (thread: 0x2c3d3461e00)…
Nov 06 19:19:30 adns debug Sending DNS query to 10.1.1.254
Nov 06 19:19:30 socket debug server.lua: closed client handler and removed socket from list
Nov 06 19:19:30 adns debug Reply for focus.mydomain.org (thread: 0x2c3d3461e00)
Nov 06 19:19:30 mod_s2s debug DNS lookup failed to get a response for focus.mydomain.org
Nov 06 19:19:30 s2sout2c3ca783600 info Failed in all attempts to connect to focus.mydomain.org
Nov 06 19:19:30 mod_s2s debug No other records to try for focus.mydomain.org - destroying
Nov 06 19:19:30 s2sout2c3ca783600 debug Destroying outgoing session mydomain.org->focus.mydomain.org: DNS resolution failed
Nov 06 19:19:30 s2sout2c3ca783600 info Sending error replies for 1 queued stanzas because of failed outgoing connection to focus.mydomain.org
Nov 06 19:19:30 stanzarouter debug Received[s2sin]:

It’s not clear to me which component is doing this request and why. Is it necessary or I have this because made a mistake somewhere before.

Regards


Alone in the room
#2

Your prosody server does not recognize the domain focus.mydomain.org and tries to connects to it as it tries to resole which is the server responsible for it.


#3

But why does it try the domain focus.mydomain.org, where does it come from ?

I followed (tried) the documentation. I have this in my prosody configuration.

Component “focus.jitsi.mydomain.org
component_secret = “YOURSECRET2”


#4

Maybe from jicofo, jicofo is using the component focus.xxxx. Check the params you pass to jicofo.


#5

I started jifoco with this command

./jicofo.sh --domain=jitsi.mydomain.org --secret=YOURSECRET2 --user_domain=auth.mydomain.org --user_name=focus –user_password=focuspassword

Is there any other place where could hide this parameter with jifoco ?

Could that be this parameter in config.js ?

    // Focus component domain. Defaults to focus.<domain>.
    // focus: 'focus.jitsi-meet.example.com',

I don’t understand the purpose of this authentication window. What is it for ?
I just followed this page.


#6

If you have not configured secure domain. When you open jitsi-meet it tries to create an anonymous xmpp connection using your default virtual host:

VirtualHost "jitsi.example.com"
    authentication = "anonymous"

But it seems it cannot create the anonymous connection and requests authentication which will result showing the user/pass window.

Did you check whether prosody loads your config, I mean are there any errors in prosody logs when you restart it?


#7

Hello,

Thank you for your answer.
I digged in my prosody logs and found errors and worked again on my configuration file.

For some reason, right now I have SSL errors when I launch jifoco

Jicofo 2018-11-08 23:29:47.965 SEVERE: [16] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.doConnect().319 Failed to connect/login: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 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: sun.security.validator.ValidatorException: 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:1072)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:994)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1010)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: 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.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
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:1067)
… 3 more

I didn’t have that error 3 days ago.

When I did a tcpdump it tries to connect to port 5222 and 5347 (component).

I’m on a private lan, is it possible to disable the SSL ?

I use the command
./jicofo.sh --domain=jitsi.mydomain.org --secret=YOURSECRET2 --user_domain=auth.jitsi.mydomain.org --user_name=focus --user_password=focuspassword

Is it correct to say that it will try to connect to jitsi.mydomain.org and match the following prosody virtual host ?

VirtualHost “jitsi.mydomain.org
enabled = true
authentication = “anonymous”
key = “/etc/prosody/certs/xmpp.mydomain.org.key”;
certificate = “/etc/prosody/certs/xmpp.mydomain.org.crt”;

modules_enabled = {
    "bosh";
    "pubsub";
    "ping";
}
c2s_require_encryption = false

#8

You can add to jicofo config which normally is /etc/jitsi/jicofo/sip-communicator.properties files, but not sure where it is when running from source maybe its ~/.sip-communicator/sip-communicator.properties:

org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true

#9

Hello Damencho,
I still have the same error but in the first place I don’t understand what jicofo is trying to do.

Nov 09 10:45:25 socket debug server.lua: accepted new client connection from 10.1.1.x:9787 to 5222
Nov 09 10:45:25 c2s59e32565f80 info Client connected
Nov 09 10:45:25 c2s59e32565f80 debug Client sent opening stream:stream to auth.jitsi.mydomain.org.net
Nov 09 10:45:25 c2s59e32565f80 debug Sent reply stream:stream to client
Nov 09 10:45:25 c2s59e32565f80 debug Not offering authentication on insecure connection
Nov 09 10:45:25 c2s59e32565f80 debug Received[c2s_unauthed]:
Nov 09 10:45:25 socket debug server.lua: we need to do tls, but delaying until send buffer empty
Nov 09 10:45:25 c2s59e32565f80 debug TLS negotiation started for c2s_unauthed…
Nov 09 10:45:25 socket debug server.lua: attempting to start tls on tcp{client}: 0x59ea1fed028
Nov 09 10:45:25 socket debug server.lua: accepted new client connection from 10.1.1.x:15582 to 5347
Nov 09 10:45:25 jcp59e833f4080 info Incoming Jabber component connection
Nov 09 10:45:25 jcp59e833f4080 debug Received[component_unauthed]:
Nov 09 10:45:25 focus.jitsi.mydomain.org:component info External component successfully authenticated
Nov 09 10:45:25 socket debug server.lua: ssl handshake error: sslv3 alert certificate unknown
Nov 09 10:45:25 c2s59e32565f80 info Client disconnected: ssl handshake error: sslv3 alert certificate unknown
Nov 09 10:45:25 c2s59e32565f80 debug Destroying session for (unknown) ((unknown)@auth.jitsi.mydomain.org): ssl handshake error: sslv3 alert certificate unknown
Nov 09 10:45:25 socket debug server.lua: closed client handler and removed socket from list

So I don’t understand what jicofo is trying to do:

  • Authenticate in clear text
  • Then switch to another port but then there’s an handshake error coming from… jicofo maybe ?

By the way I added to ~/.sip-communicator/sip-communicator.properties

org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true

But there’s no certificate on port 5347.

On the tcpdump capture I can see that the jifoco server is replying

TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Certificate Unknown (46)

And before that there was 5 messages from the xmpp server to jicofo

<stream:stream xmlns=“jabber:component:accept” xmlns:stream=“http://etherx.jabber.org/streams” to=“focus.jitsi.mydomain.org”>

<?xml version='1.0'?>

b6eda8b26803885c9460183aa79ce2695a1900a5

Regards


#10

Hello Regarding this whole problem,

It seems to me that

org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true

doesn’t work

I had to import the Let’s Encrypt chain in the java certificate store which is different than the certificate store that openssl command uses.

I still have problems and jitsi doesn’t work but this thread will be too long to follow