Lo sto facendo da più di un anno con alcuni script da una casella Linux a un'altra. Consentitemi di delineare cosa sto facendo, poiché non potrò condividere gli script. Inoltre, stai utilizzando Windows da un lato, quindi alcuni script di shell sarebbero abbastanza inutili.
Il certbot client utilizza un URI ben noto denominato /.well-known per posizionare il file token utilizzato per la convalida del dominio automatizzata tramite HTTP (utilizzando l'autenticatore / plugin webroot ).
Ora quello che ho fatto per quei pochi domini situati su ciò che è nel tuo caso 123.123.123.2, era abilitare HTTP (cioè porta 80) su 123.123.123.1 e configurare gli host virtuali per foo.example.com e bar.example.com rispettivamente.
L'host virtuale è stato quindi configurato (in Nginx) per puntare a una posizione fisica per l'URI /.well-known in modo che certbot sia in grado di posizionare il file di token in tale percorso:
location /.well-known/ {
alias /your/path/.well-known/;
autoindex on;
try_files $uri $uri/ =404;
limit_except GET {
deny all;
}
}
In questo modo posso usare webroot authenticator di certbot e puntare alla radice web di detto "dominio falso" (è falso perché è un host virtuale su 123.123.123.1 mentre le voci DNS per quel dominio puntano a 123.123.123.2).
Ora non è dove finisce, ma è il primo passo.
Sull'altra macchina in cui il effettivamente punta a I installato rinetd per tornare a 123.123.123.1 (la macchina che esegue certbot) sulla porta 80. In /etc/rinetd.conf questo assomiglia a:
127.0.0.1 8080 123.123.123.1 80
Allo stesso tempo tutte le richieste a /.well-known per siti foo.example.com e bar.example.com su 123.123.123.2 sono silenziosamente inoltrate a 127.0.0.1 porta 80, lasciando i parametri HTTP (nome host e URI intatti).
Usando questo metodo certbot (in esecuzione su .1), ad esempio, creerai un file token /your/path/.well-known/foobar e Letsencrypt tenterà di accedere a http://foo.example.com/.well-known/foobar . Quella richiesta, come al solito, finirà sulla macchina a cui puntano i record DNS. Quindi finisce su .2 dove il server HTTP è configurato per inoltrare silenziosamente richieste per gli elementi al di sotto dell'URI /.well-known a 127.0.0.1 porta 8080, che rinetd usa per inoltrare i pacchetti alla porta 123.123.123.1 80. E quindi noi chiudi il cerchio e certbot sarà in grado di fare la sua routine di validazione del dominio.
Ahimè, sto eseguendo questo su Linux, quindi con la tua configurazione apparentemente un server Windows, dovrai trovare (o creare) qualcosa come rinetd per Windows. Anche se questo non può essere di aiuto direttamente, forse aiuta qualcun altro ad avere un problema simile con due Linux box.
L'intera routine rinetd ha lo scopo di ottenere intatte le intestazioni HTTP su 123.123.123.1, in modo tale che l'host virtuale per quel dominio abbia effetto su 123.123.123.1.
Usando questa routine uno dei miei server esegue il rinnovo per una serie di altre macchine che effettivamente ospitano singoli sottodomini.
Oh e su un'altra nota. Il tuo scenario è solo molto esplicito. Se vuoi eseguire XMPP o un MTA e la ricerca del servizio non è strettamente legata solo alla ricerca DNS dei record A / AAAA o CNAME, finirai in una situazione che è tecnicamente uguale al tuo.
Se qualcuno ha un'idea più intelligente su come risolverlo, fammi un messaggio nei commenti a questa risposta.