Quero perguntar se é possível usar o Certbot para uma configuração semiautomática em que a infraestrutura subjacente seja controlada por mim e não pelo Certbot.
Entendo que o Certbot se comunicará com a Let's Encrypt para emitir um desafio, que é basicamente um token que o Certbot precisará encontrar no meu endereço IP ou no meu DNS.
Eu tenho controle total do servidor Apache, mas é uma configuração de hospedagem múltipla muito personalizada (é necessário SNI!) e não quero que o Certbot estrague minha configuração do Apache, nem seja executado como root. Voltaremos aos sudoers mais tarde.
Já configurei o espaço de hospedagem para mta-sts.example.org
, pois estou implementando o Strict Transport Security do Mail Transfer Agent
Eu disse ao Apache, usando uma macro, que /home/djechelon/srv/www/domains/mta-sts.example.org
é minha área de trabalho
- htdocs: conteúdo veiculado por HTTP
- htdocs-secure: conteúdo veiculado por HTTPS
- logs: logs do Apache VHost
- ssl: é aqui que
mta-sts.example.org.{key,crt,ca_bundle?}
existe
Eu gostaria de dizer ao Certbot para fazer o seguinte por mim
- Obtenha o desafio de LE
- Escreva o desafio no arquivo apropriado em
/home/djechelon/..../htdocs
, e o Apache estará pronto para atendê-lo - Peça ao LE para validar o desafio, porque o Apache está pronto para atender ao desafio
- Gravar certificado para
/home/djechelon/..../ssl/
. Se o LE não fornecer ca_bundle sem problemas, é opcional no meu lugar - Emita o recarregamento do Apache (provavelmente haverá uma configuração de sudoers em breve)
Eu entendi que preciso usar o webroot
plugin neste caso, mas estava lutando para encontrar ajuda de linha de comando para todas as opções, incluindo onde armazenar os arquivos e os certificados.
A documentação pressupõe que o processo é interativo, então eu teria que copiar o arquivo de desafio manualmente e pedir ao Certbot para entrar em contato com o LE para validação do domínio.
Acredito que deve haver uma maneira simples de executar o script simples acima, que é executado sob a suposição de que a infraestrutura geral de TI existe (por exemplo, você realmente deseja executar seu próprio software de servidor) e está bem configurada.
Qualquer ajuda?
[Edit] Consegui invocar isso interativamente por enquanto
certbot certonly --webroot -d mta-sts.example.org --preferred-challenges http --work-dir /home/djechelon/etc/letsencrypt --logs-dir /home/djechelon/letsencrypt-logs --config-dir /home/djechelon/etc/letsencrypt
Que me pediu o diretório webroot e o email (algo que eu adoraria passar como parâmetro para futuras renovações). Então agora a pergunta pode se tornar "como faço para reexecutar isso no futuro não interativamente com o cron?"
Eu não armazenaria os certificados no diretório inicial do usuário (
/home/djechelon/..../ssl/
) porque, se o usuário remover os arquivos de certificado, o Apache falhará ao iniciar . Concordo com o seu raciocínio de que é melhor que o Certbot não mexa com a configuração do servidor web, mas atualmente parece que você está efetivamente causando o mesmo problema que está tentando evitar e, portanto, estou tentando avisá-lo.Não há razão para usar o diretório home para desafios HTTP-01 nem arquivos de log, e também é possível usar uma configuração estática com o Apache, usando o Certbot no
certonly
modo como você já faz.Minha solução para renovações automáticas está usando o mesmo diretório de trabalho para todos os desafios HTTP-01 (de
/etc/letsencrypt/renewal/example.com.conf
):Dessa forma, é possível adicionar um global
Alias
que lide com todos os desafios, mas também é possível colocá-lo apenas nos hosts virtuais onde for necessário:Provavelmente o modo interativo deve ser executado apenas uma vez. O Certbot lembra onde os certificados estão armazenados, e isso está sempre no diretório de trabalho.
Não tão ruim assim. Minha solução foi substituir
/home/djechelon/srv/..../ssl/*
por links simbólicosResumidamente:
certbot renew
com o diretório de trabalho adequado para executar como não raizComando de emissão
Comando de renovação (pode ser
cron
-ned talvez)Na renovação, é claro, deve-se agendar uma recarga do Apache no mínimo