Espero usar o Let's Encrypt para vários domínios e subdomínios e para minha empresa. Em vez de comprar um certificado curinga de longa duração instalado em todas as máquinas, o objetivo é usar certificados específicos e de curta duração. Isso evita nossa exposição se uma máquina for comprometida.
Infelizmente, alguns servidores não podem ter nenhuma interrupção de serviço (também conhecida como nenhuma capacidade de desafio HTTP acme). Portanto, a opção final é o desafio do DNS. Isso requer um token de API para nosso provedor de DNS, neste caso, Cloudflare.
No entanto, se eu colocar o Global API Token na máquina e ele for comprometido, isso dará ao invasor acesso total ao nosso DNS para todo o domínio. Isso é exatamente o que quero mitigar, não usando um certificado curinga.
Cloudflare permite criar tokens menos privilegiados, mas eles não são mais granulares do que por domínio de nível raiz. Novamente, essencialmente o mesmo acesso/preocupação do certificado curinga.
Alguém encontrou uma solução para esse problema?
Responder1
A abordagem que adoptei no passado para este requisito, e que consideroacreditaré abençoado pela documentação do Let's Encrypt, é CNAME o _acme-challengesubdomínio para o(s) nome(s) que você deseja validar para nomes em uma ou mais zonas, que possuem diferentes configurações de controle de acesso.
Por exemplo, se você deseja permitir que algum serviço gere certificados apenas para bobservice.example.com, você pode criar uma zona separada para algum outro domínio, digamos bobservice.example, e depois CNAME _acme-challenge.bobservice.compara _acme-challenge.bobservice.example. O token de desafio é então colocado em um registro TXT em _acme-challenge.bobservice.example, LE segue o CNAME e o nome é validado.
Claro, a outra opção é deixar de usar o Cloudflare totalmente, porque seu serviço carece de recursos úteis, como credenciais de escopo limitado, e também o minúsculo problema de fornecer serviços para a escória da Internet.
Responder2
Infelizmente, alguns servidores não podem ter nenhuma interrupção de serviço (também conhecida como nenhuma capacidade de desafio HTTP acme). Portanto, a opção final é o desafio do DNS.
Há outra opção para o seu tipo de cenário, oplugin webroot. Isso permite que você informe ao cliente Let's Encrypt o caminho para a raiz da web do seu servidor e colocará os arquivos de desafio HTTP lá. Essa abordagem não atrapalha o seu servidor web e não provoca nenhum tempo de inatividade.
Responder3
Minha solução é construir um serviço que resida na rede interna, seja bastante bloqueado e possua a chave da API Global. Este serviço usará esta chave para criar/renovar certificados para vários subdomínios. Os servidores que dependem dos certificados de subdomínio terão um token por domínio que podem emitir neste serviço interno para recuperar um certificado novo ou renovado.