#gajim got itself back on my 'always started' list
Somehow there seems to be a renewed interest in #xmpp? #notcomplaining
@stevenroose @dino Thanks. I have it installed, but it has problems with my jid (marcel@hsdev.com) residing on a server with a cert named as xmpp.hsdev.com
I haven't dived in if that is a config issue on my end, but gajim (and most other clients) just work for me.
@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.
Ensure that your #Letsencrypt client can write to http://hsdev.com/.well-known/acme-challenge (locally or via #sftp). The #ACME client can run in either blah.net or hsdev.com—in the latter case you sftp the certificates across to blah.net.
Point your XMPP server to the location where #PEM file ends up after renewal. Ensure your XMPP server is reloaded / restarted after renewal.
2/2
@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:
- hsdev.com and xmpp.hsdev.com are 2 (or more) different machines which all need certificates for hsdev.com, 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 https://github.com/srvrco/getssl which takes care of all that. The user running getssl in blah.net should be able to #SFTP into hsdev.com 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
ACL=('ssh:user@hsdev.com:/path/to/.well-known/acme-challenge')
# Reload
RELOAD_CMD="sudo service ejabberd reload"
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:
https://account.conversations.im/domain/
Run by the #Conversations dev, one of the main forces behind XMPP these days.
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.
@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 conversations.im or quicksy.im actually talk to you?
What does https://compliance.conversations.im/ say?
@0 @stevenroose @dino
compliance.conversations.im 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.
@0 @stevenroose @dino I'm in too deep already ;-) This xmpp service has been running for years.... #selfhosted