He estado haciendo esto durante más de un año con algunos scripts de una caja de Linux a otra. Permítame describir qué estoy haciendo, ya que no podré compartir los scripts. Además, está utilizando Windows en un extremo, por lo que algunos scripts de shell serían bastante inútiles.
El cliente certbot usa un URI conocido denominado /.well-known para colocar el archivo de token utilizado para la validación del dominio automatizado a través de HTTP (mediante el uso de webroot authenticator / plugin).
Ahora, lo que hice para esos pocos dominios ubicados en su caso 123.123.123.2, fue habilitar HTTP (es decir, el puerto 80) en 123.123.123.1 y configurar los hosts virtuales para foo.example.com y bar.example.com respectivamente.
Ese host virtual se configuró (en Nginx) para apuntar a una ubicación física para URI /.well-known para que certbot pudiera colocar el archivo de token en esa ruta:
location /.well-known/ {
alias /your/path/.well-known/;
autoindex on;
try_files $uri $uri/ =404;
limit_except GET {
deny all;
}
}
De esta manera puedo usar el autenticador webroot de certbot y apuntar a la raíz web de dicho "dominio falso" (es falso porque es un host virtual en 123.123.123.1 mientras que las entradas de DNS para ese dominio apuntan a 123.123.123.2).
Ahora no es donde termina, pero es el primer paso.
En la otra máquina donde el DNS en realidad apunta a que instalé rinetd para que apunte a 123.123.123.1 (la máquina que ejecuta certbot) en el puerto 80. En /etc/rinetd.conf , esto se ve así:
127.0.0.1 8080 123.123.123.1 80
Al mismo tiempo, todas las solicitudes a /.well-known para los sitios foo.example.com y bar.example.com en 123.123.123.2 se procesan de forma silenciosa en el puerto 80.0.0.1, mientras se dejan los parámetros HTTP (el nombre de host y el URI están intactos). / p>
Al utilizar estos métodos, certbot (ejecutándose en .1), por ejemplo, creará un archivo de token /your/path/.well-known/foobar y Letsencrypt intentará acceder a http://foo.example.com/.well-known/foobar . Dicha solicitud terminará, como es habitual, en la máquina a la que apuntan los registros DNS. Entonces termina en .2 donde el servidor HTTP está configurado para reenviar silenciosamente las solicitudes de elementos debajo del URI /.well-known al puerto 8080.0.0.1 8080, que rinetd usa para reenviar los paquetes al puerto 80.123.123.1. De este modo, cierre el círculo y certbot podrá realizar su rutina de validación de dominio.
Desafortunadamente, estoy ejecutando esto en Linux, por lo que con su configuración aparentemente siendo un servidor de Windows, tendrá que encontrar (o crear) algo como rinetd para Windows. Aunque esto no ayude directamente, quizás ayude a otra persona que tenga un problema similar con dos cajas de Linux.
La rutina rinetd está dirigida a mantener intactos los encabezados HTTP de 123.123.123.1, de modo que el host virtual para ese dominio tenga efecto en 123.123.123.1.
Al utilizar esta rutina, uno de mis servidores realiza la renovación de una serie de otras máquinas que en realidad albergan subdominios individuales.
Ah y en otra nota. Tu escenario es solo muy explícito. Si desea ejecutar XMPP o un MTA y la búsqueda del servicio no está estrictamente vinculada solo a la búsqueda de DNS de los registros A / AAAA o CNAME, terminará en una situación que técnicamente es lo mismo que el tuyo.
Si alguien tiene una idea más inteligente sobre cómo resolver esto, envíeme un grito en los comentarios a esta respuesta.