got itself back on my 'always started' list

Somehow there seems to be a renewed interest in ?

@stevenroose @dino Thanks. I have it installed, but it has problems with my jid ( residing on a server with a cert named as

I haven't dived in if that is a config issue on my end, but gajim (and most other clients) just work for me.

@mrb @dino Hmm, I think you should have a certificate that's issued for the JID domain IIRC, yes.

@stevenroose @dino In my case, that's impossible, because the main domain points somewhere else.

@mrb @dino Why is that impossible? It doesn't matter where the domain "points to", right? It can point to wherever, but you can still have a certificate issued for that domain in another server.
I to reckon that when you're using Let's Encrypt and using the HTTP ACME challenge, it's tricky. Perhaps you should look for a domain seller that provides free DNS-based Let's Encrypt certificates?

@stevenroose @dino impossible as in "I don't know how to do that with letsencrypt certs yet"

i definitely would like to use letsencrypt.


Why is your cert if your FQDN is

Let's assume that your #XMPP server runs on

On your #DNS zone for hsdev add:

_xmpp-client._tcp 10800 IN SRV 20 0 5222
_xmpp-server._tcp 10800 IN SRV 10 0 5269

@stevenroose @dino


@mrb @stevenroose @dino

Ensure that your #Letsencrypt client can write to (locally or via #sftp). The #ACME client can run in either or—in the latter case you sftp the certificates across to

Point your XMPP server to the location where #PEM file ends up after renewal. Ensure your XMPP server is reloaded / restarted after renewal.


@0 @stevenroose @dino
Thanks for the info!

sftp part, time and knowledge gaps kept me from doing this so far

What I need, which may very well be possible, just havent gotten around to finding out how:

- and are 2 (or more) different machines which all need certificates for, preferably different
- unattended renewal needs to work on all those machines with certbot (this perhaps implies dns auth for letsencrypt?)
- scaling up and down needs to be simple


I use #getssl which takes care of all that. The user running getssl in should be able to #SFTP into with write access to /.well-known/acme-challenge (man ssh-copy-id)

The relevant lines in the getssl.cfg file then are:

# #ACME challenge location
# Reload
RELOAD_CMD="sudo service ejabberd reload"

@stevenroose @dino

@mrb @stevenroose @dino

The reason I use #GetSSL as opposed to #Certbot is that the former does not expect to run as #root. It is run as an unprivileged user.

@mrb @stevenroose @dino

Or of course, if you just want to have #XMPP up and running and not bother with the intricacies of it all, just go for this:

Run by the #Conversations dev, one of the main forces behind XMPP these days.

@0 @stevenroose @dino I'm in too deep already ;-) This xmpp service has been running for years....


Ok, I suggest you get it configured properly then, for the sake of anyone trying to communicate with you.

The only reason it “runs” is because at some point you must have accepted the misconfigured certificate in your client (or your client is buggy).

Trying to communicate with anyone residing on a different server will be impossible if the latter is properly configured.

@stevenroose @dino


@0 @stevenroose @dino strangely, that literally has never happened in years


That's interesting. Peers should failing the connection upon checking the server name. Can someone at say or actually talk to you?

What does say?

@stevenroose @dino

@0 @stevenroose @dino won't let me submit, says "Credentials could not be verified"
(i verified the test account with two other clients as working properly)

@0 @stevenroose @dino Updated the cert manually, compliance tests now work.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!