@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?
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"
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!