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.
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
RELOAD_CMD="sudo service ejabberd reload"
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.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!