No certificate present in SSL/TLS configuration for https port 5284

When I install on jitsi-meet on a fresh server prosody reports errors.

Prosody reports:
portmanager: Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5284

systemd[1]: Started Prosody XMPP Server.

I can resolve by adding https_certificate and https_key to /etc/prosody/conf.d/jitsi.example.com.cfg.lua

https_certificate = "/etc/prosody/certs/jitsi.example.com.crt";
https_key =  "/etc/prosody/certs/jitsi.example.com.key";

In general it appears the prosody configuration is for a previous version and not 10 and above.
https://prosody.im/doc/configure#certificates_-_010

I’m happy to help test or fork and contribute, providing I’m not duplicating effort.

My current running environment:

$ uname -a 
Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 GNU/Linux

$ apt list jicofo jitsi-* --installed
jicofo/stable,now 1.0-549-1 all [installed,automatic]
jitsi-meet-prosody/stable,now 1.0.4025-1 all [installed,automatic]
jitsi-meet-turnserver/stable,now 1.0.4025-1 all [installed,automatic]
jitsi-meet-web-config/stable,now 1.0.4025-1 all [installed,automatic]
jitsi-meet-web/stable,now 1.0.4025-1 all [installed,automatic]
jitsi-meet/stable,now 2.0.4468-1 all [installed]
jitsi-videobridge2/stable,now 2.1-183-gdbddd169-1 all [installed,automatic]
1 Like

I see. You are saying that this needs to be replaced:
https://github.com/jitsi/jitsi-meet/blob/master/doc/debian/jitsi-meet-prosody/prosody.cfg.lua-jvb.example#L28?
What about just removing it? Does it work without that setting as it says it should be auto-detected?

In general, this is not a problem as port 5281 is not used at all, bosh is proxied through the http clear port.

It doesn’t seem to work for me without the two https keys. I’m wondering if I am missing something in the settings, because it seems to mandate https. I can try adding consider_bosh_secure = true to the global section?

This is the documentation I was reading at the time:
https://prosody.im/doc/setting_up_bosh#proxying_requests

I have found I can take out all of the other certificate paths from the configuration and it will auto detect the correct certificates in the /etc/prosody/certs folder.

Is already in the default install:

So it is, going cross eyed tonight!

consider_bosh_secure = true;
-- https_certificate = "/etc/prosody/certs/jitsi.example.com.crt";
-- https_key =  "/etc/prosody/certs/jitsi.example.com.key";

Results in:

portmanager: Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281

Then the service shuts down.

When I re-add the HTTPS properties to prosody it works correctly again. I’ve tried this as a clean install, following the quick guide. I understand both HTTP and HTTPS endpoints are started and I only need HTTP.

Here’s /var/log/prosody/prosody.log with the domain replaced to jitsi.example.com:

Apr 29 22:30:31 startup info    Prosody is using the select backend for connection handling
Apr 29 22:30:31 portmanager     info    Activated service 'component' on [127.0.0.1]:5347, [::1]:5347
Apr 29 22:30:31 portmanager     info    Activated service 's2s' on [*]:5269, [::]:5269
Apr 29 22:30:31 portmanager     info    Activated service 'c2s' on [*]:5222, [::]:5222
Apr 29 22:30:31 portmanager     info    Activated service 'legacy_ssl' on no ports
Apr 29 22:30:31 portmanager     info    Activated service 'http' on [*]:5280, [::]:5280
Apr 29 22:30:31 portmanager     error   Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281
Apr 29 22:30:31 portmanager     error   Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281
Apr 29 22:30:31 portmanager     info    Activated service 'https' on no ports
Apr 29 22:30:31 general info    Starting conference duration timer for conference.jitsi.example.com
Apr 29 22:30:31 conferenceduration.jitsi.example.com:conference_duration_component        info    No muc component found, will listen for it: conference.jitsi.example.com
Apr 29 22:30:31 general info    Starting speakerstats for conference.jitsi.example.com
Apr 29 22:30:31 speakerstats.jitsi.example.com:speakerstats_component     info    No muc component found, will listen for it: conference.jitsi.example.com
Apr 29 22:30:31 speakerstats.jitsi.example.com:speakerstats_component     info    Hook to muc events on conference.jitsi.example.com
Apr 29 22:30:31 conferenceduration.jitsi.example.com:conference_duration_component        info    Hook to muc events on conference.jitsi.example.com
Apr 29 22:30:31 general info    Shutting down...
Apr 29 22:30:31 general info    Shutdown status: Cleaning up
Apr 29 22:30:31 general info    Shutdown complete

I’ve tried again this morning using Ubuntu. The same error shows but the system appears to work and can be ignored.

When I install it on Buster it shuts down again until I add https_certificate and https_key.

Unfortunately I don’t have another server I can test on at the moment. I’m sure when I was experimenting on ARM, sometimes I would have similar. I could ignore the error on some installs and other times Prosody would shutdown. I’m not asking for support on an ARM device, only X86/X64. But it is interesting in terms of trying to figure out if the issue is environment related.

It would be far more ideal if I had another X86/X64 to test with.

  1. consider_bosh_secure = true does not seem to effect the issue because Prosody shuts downs before NGINX gets a chance to communicate and bounce. In fact I’ve shutdown jicofo, jitsi-videobridge2 and nginx, Prosody still shuts itself down.
  2. Whether it works does not seem to be related to a particular Prosody version, I’m running 0.11.2-1 on all platforms.
  3. It could be hardware, but then there should be some similarity between an ARM device and my HP server and as of yet I cannot find one.
  4. When installing Buster I’m only adding SSH during the install and running apt update and apt -y upgrade before installing Jitsi Meet. It could be a software conflict, but it should not be.

This one has stumped me. What are your thoughts?

1 Like

I have no idea why Prosody shuts down on Buster but not on Ubuntu with this error. To get rid of the error, can you try to disable the https port by adding

https_ports = { }

to the main prosody config? This option is part of the http module which is likely pulled in by the bosh module, docu for the http mod can be found here?

2 Likes

Thank you @plokta and that works for me. I’m going to do more testing, but that seems to be a very elegant solution. I really like it.

Hello!

had the same problem, and solved by adding:

ssl = {
key = “/etc/prosody/certs/somevideo.somedomain.com.key”;
certificate = “/etc/prosody/certs/somevideo.somedomain.com.crt”;
– new lines below
https_certificate = “/etc/prosody/certs/somevideo.somedomain.com.crt”;
https_key = “/etc/prosody/certs/somevideo.somedomain.com.key”;
}

to
VirtualHost “somevideo.somedomain.com
and
VirtualHost “auth.somevideo.somedomain.com”

in log files, no more error messages like
portmanager: Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281

Question is: how can I check if prosody is replying to request on port 5281 or 5280?
A Curl will return 404 …

To check the ports have you tried profanity?

Also have you tried https_ports = { } in the global section (suggested here) as an alternative to https_certificate and https_key? If so what kind of success did you have?

1 Like

I’d like to check what messages it returns, if any…
Profanity looks good, gonna try it! Thanks!

Also, my main issue is when activating Etherpad. Adding parameter to VideoBrige config file:

JVB_OPTS="–apis=rest, xmpp"

will result in all Jitsi Meet to freeze and stop working…

@tigerhiddenadam your method works for me jitsi-meet stable-6433

  • prosody/now 0.11.7-1~bionic4