Espero utilizar Let's Encrypt para varios dominios y subdominios y para mi empresa. En lugar de comprar un certificado comodín de larga duración que se instala en cada máquina, el objetivo es utilizar certificados específicos y de corta duración. Esto es para evitar nuestra exposición si una máquina se ve comprometida.
Desafortunadamente, algunos servidores no pueden tener ninguna interrupción del servicio (es decir, no tienen capacidad de desafío HTTP Acme). Entonces, la última opción es el desafío DNS. Esto requiere un token API para nuestro proveedor de DNS, en este caso, Cloudflare.
Sin embargo, si coloco el token API global en la máquina y se ve comprometido, esto le da al atacante acceso completo a nuestro DNS para todo ese dominio. Esto es exactamente lo que quiero mitigar al no utilizar un certificado comodín.
Cloudflare le permite crear tokens con menos privilegios, sin embargo, no se vuelven más granulares que por dominio de nivel raíz. Nuevamente, esencialmente el mismo acceso/preocupación que el certificado comodín.
¿Alguien ha encontrado una solución a este problema?
Respuesta1
El enfoque que he adoptado en el pasado para este requisito, y quecreerestá bendecido por la documentación de Let's Encrypt, es CNAME el _acme-challengesubdominio para los nombres que desea validar para nombres en una o más zonas, que tienen diferentes configuraciones de control de acceso.
Como ejemplo, si desea permitir que algún servicio genere certificados solo para bobservice.example.com, puede crear una zona separada para algún otro dominio, por ejemplo bobservice.example, y luego CNAME _acme-challenge.bobservice.compara _acme-challenge.bobservice.example. Luego, el token de desafío se coloca en un registro TXT el _acme-challenge.bobservice.example, LE sigue al CNAME y el nombre se valida.
Por supuesto, la otra opción es dejar de usar Cloudflare por completo, porque su servicio carece de funciones útiles como credenciales de alcance limitado y también el pequeño problema de que brindan servicios a la escoria de Internet.
Respuesta2
Desafortunadamente, algunos servidores no pueden tener ninguna interrupción del servicio (es decir, no tienen capacidad de desafío HTTP Acme). Entonces, la última opción es el desafío DNS.
Hay otra opción para tu tipo de escenario, lacomplemento webroot. Esto le permite indicarle al cliente Let's Encrypt la ruta a la raíz web de su servidor y colocará los archivos de desafío HTTP allí. Este enfoque no afecta en absoluto a su servidor web y no genera tiempo de inactividad.
Respuesta3
Mi solución es crear un servicio que resida en la red interna, esté bastante bloqueado y contenga la clave API global. Este servicio utilizará esta clave para crear/renovar certificados para varios subdominios. Los servidores que dependen de los certificados de subdominio tendrán un token por dominio que pueden emitir contra este servicio interno para recuperar un certificado nuevo o renovado.