Need Help with Lobby with Tokens

What about ownership? What should ownership of server blocks look like? right now it is root:root

Ssi not ssl, server side includes

# ssi on with javascript for multidomain variables in config.js
ssi on;
ssi_types application/x-javascript application/javascript;

It is only on for port 443, however, not port 80, but since everything should be going over port 443, this should not be an issue.

I don’t need to add a lot of more garbage below, it looks like my SSL Cert isn’t being read or recognized or isn’t in the proper form, or may not have the right permission/ownership.

This is a Wildcard cert and every subdomain should find a match. Perhaps I made an mistake when I combined the Cert with the Bundle.

Otherwise, here is where config is referenced in the JS:

de = {
cacheUserLanguage: Function.prototype,
lookup: () => config.defaultLanguage,
name: “configLanguageDetector”
},
… … …

Also I found these errors:

Oct 17 01:08:05 certmanager error SSL/TLS: Failed to load ‘/etc/ssl/comodo/ssl.key/politea_us.key’: Check that the file contains a certificate (for https port 5281)
Oct 17 01:08:05 portmanager error Error binding encrypted port for https: error loading certificate (no start line)

Not sure how I add port 5281 to the certificate, but I think I have to copy the cert block and add port 5281 at the top.

And still more errors:

Oct 17 01:08:05 modulemanager error Error initializing module ‘muc_size’ on ‘meet.politea.us’: /usr/lib/prosody/util/startup.lua:201: module ‘net.url’ not found:No LuaRocks module found for net.url
no field package.preload[‘net.url’]
no file ‘/usr/lib/prosody/net/url.lua’
no file ‘/usr/local/share/lua/5.2/net/url.lua’


Question, how much should be included with regard to SSL in /etc/prosody/prosody.cfg.lua and how much should be included in /etc/prosody/sites-available/FQDN.cfg.lua.

Seem to me that I don’t want duplication here.

How could I check to see if Jitsi is using Jetty instead of Nginx?

ps ax| grep nginx
netsta -anp| grep 443
Jetty is not default since more than an year

The problem I am having is with SSL. I am seeing private key does not match public key in prosody,err, Certificate does not match hostname in jvb.log and Certificate does not match hostname
java.security.cert.CertificateException: No subject alternative DNS name matching auth.meet.politea.us found. Tried: *.politea.us,politea.us in jicofo.log, and yet in every other application there is no problem using these. Perhaps it is the nested subdomain that it is causing the problem. So far Comodo hasn’t responded with any information.

As far as Jetty, I am just trying to eliminate every other possibility, So thanks, that is ps ax | grep nginx, and netstat -anp | grep 443?

root@meet:/etc/jitsi/jicofo# ps ax | grep nginx
898 ? Ss 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
899 ? S 0:00 nginx: worker process
5060 pts/0 S+ 0:00 grep --color=auto nginx
root@meet:/etc/jitsi/jicofo# netsta -anp | grep 443

root@meet:/# netstat -anp | grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 898/nginx: master p
tcp6 0 0 :::443 :::* LISTEN 898/nginx: master p

I thought I found the problem when I renamed the cert and found that I had made a typo in FQDN.cfg.lua, but I fixed that and now have a new error:

Jicofo 2020-10-18 00:00:04.699 SEVERE: [522] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: SASLError using SCRAM-SHA-1: not-authorized.

2020-10-17 00:00:03.752 INFO: [37319] org.jivesoftware.smack.java7.XmppHostnameVerifier.verify: Certificate does not match hostname
java.security.cert.CertificateException: No subject alternative DNS name matching auth.meet.politea.us found. Tried: *.politea.us,politea.us,

|Oct 18 00:00:04 certmanager|error|SSL/TLS: Error initialising for callcontrol.meet.politea.us: private key does not match public key|
|---|---|---|
|Oct 18 00:00:04 callcontrol.meet.politea.us:tls|error|Error creating context for c2s: private key does not match public key|

Perhaps I need to create an OpenSSL cert via Ubuntu and use that for internal security and use the Comodo cert for public facing Nginx security.

Nginx is happy with the Cert as it is, but Prosody isn’t.

This cert is good for *.politea.us, so is should be good for all subdomains like meet.politea.us and auth.meet.politea.us abd guest.meet.politea.us

Not for the last two … * Covers only one subdomain

Can’t I purchase a cert from Comodo that would cover any port and any level of subdomain. The reason we purchased this was for reputation verification beyond just encryption.

I will just use the Jitsi generated certs for Prosody and the Comodo cert for Nginx.

Thanks for the heads up again D.

In /var/lib/prosody the ownership of the cert and key files is prosody:prosody, while the sim-links in /etc/prosody/certs is root:root.

I am getting the error

Jicofo 2020-10-18 19:41:03.135 SEVERE: [321] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: SASLError using SCRAM-SHA-1: not-authorized
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized

And was wondering if this was an ownership issue

systemctl status on everything indicates that everything is loaded and running normally. Yet I am getting these errors reported in the logs. Cleared the log files to make sure this wasn’t stale info.

If Nginx listens on port 443, should Prosody then listen on port 4444? since I will use the Comodo cert for Nginx and the OpenSSL cert for everything Jitsi.

So I am going to generate new Let’s Encrypt SSL Certs for FQDN and auth.FQDN. Is there anything I should be aware of while doing this.

Comodo confirmed, they only recognize the first level subdomain for the Cert we purchased, which means it will work for Nginx, and not for Prosody and it’s many second level subdomains. The same would be true of Jibri as well, I assume.

official certificates are not used for Prosody sites.

What is the reason for that?

I am using certbot to create certs for FQDN and auth.FQDN in the hopes of getting Prosody to like it.

What else do I have to do to get Prosody to like the certs?

because they are not supposed to accessed as such from a browser. The browser accesses the main site and it’s protected by TLS, and then Javascript code use this TLS protected connection to do Prosody (Xmpp) Api calls managing users and presences in these sites. There is no need to use the official certificate again, it’s already used with the main site.

certbot complains that there is no A record for auth.FQDN, which there isn’t, there is an A recond for FQDN only. Do I just ignore the cerbot warning?

Or do I need to purge Prosody, Jicofo and Jitsi-videobridge2 and reinstall Jitsi and let Jitsi create the certs it needs.

Well, I can’t get anything to work, so I will reinstall Jitsi, after backing up all the config files.

This ssl situation is really a nightmare on Jitsi. forgot to delete all the old configuration files so nothing got done really.

But it should not be this difficult to manually add TLS certificates.

Could it be that Jitsi was saddled with old protocols and ciphers?

Do I need to include any TLS information in /etc/prosody/FQDN.cfg.lua?