Usando Let's Encrypt no Slackware
Antigamente, quando tudo era mato na internet, era possível navegar por sites em puro html, contendo somente texto, um ou outro gif animado e algumas fotos na "alta" qualidade de 640x480 pixels.
Nessa época era tudo despreocupadamente mais inocente, sem conexões criptografadas, onde só existia o http, com as comunicações sendo transmitidas abertas pela internet.
Com o tempo, e o avanço das compras on-line, um ambiente mais seguro se mostrou necessário. Isso provocou o desnenvolvimento dos certificados SSL (Secure Sockets Layer) que promovem criptografia de ponta a ponta na internet. Com ele habilitado por padrão nos sites modernos todo tráfego entre o site e o computador que o acessa é criptografado, impossibilitando a interceptação dos dados em trânsito.
Assim sendo, ter um certificado SSL em nossos sites é extremamente importante, por mais que seja um site de gifs animados, pois os navegadores modernos barram por padrão a abertura de sites sem um certificado SSL, com certificado vencido ou de uma autoridade desconhecida.
Uma autoridade reconhecida é um órgão ou instituição válida e idônea para emitir certificados SSL, pois estes certificados podem ser facilmente gerados hoje em dia, mas uma assinatura de uma entidade idônea é facilmente aceita pelos navegadores que checam os dados dessas entidades com o banco de dados disponíveis no computador, e atualizados periodicamente pelos mantendedores do sistema, seja Microsoft, Apple ou a distro Linux usada.
Aqui aprenderemos a conseguir um desses certificados através da Let's Encrypt, entidade que promove a fácil obtenção de certificados válidos e reconhecidos para sites a custo zero, porém com validade máxima de 90 dias, sendo necessária a renovação periódica dos mesmos, coisa que discutiremos mais adiante.
Usaremos a aplicação dehydrated que acompanha o Slackware por padrão.
Primeiramente vamos criar um job em cron para que a verificação de validade seja realizada semanalmente e caso seja necessário, atualize os certificados automaticamente.
cat << EOT > /etc/cron.d/dehydrated
# Checa a validade dos certificados do Let's Encrypt todas as segundas:
0 21 * * Mon /usr/bin/dehydrated -c >> /var/log/dehydrated 2>&1
EOT
O dehydrated usa a estrutura de diretórios abaixo do diretório /etc/dehydrated.
O arquivo de configuração principal é o "config".
O arquivo "domains.txt" contem os endereços de domínios a serem verificados para obtenção dos certificados SSL.
O diretório "accounts" será usado para armazenar os dados de conta do usuário e chaves privadas do Let's Encrypt uma vez que o registro seja feito com eles.
Um novo diretório "certs" será criado para guardar os certificados SSL criados e atualizados.
O arquivo de configuração principal do dehydrated contem comentários muito claros e aqui usarei apenas os pontos necessários para utilização.
DEHYDRATED_USER=admin
DEHYDRATED_GROUP=wheel
CA="letsencrypt"
CHALLENGETYPE="http-01"
WELLKNOWN="/usr/local/dehydrated"
PRIVATE_KEY_RENEW="no"
[email protected]
LOCKFILE="${BASEDIR}/var/lock"
HOOK=/etc/dehydrated/hook.sh
Vamos esmiuçar ponto a ponto:
- Vamos rodar o dehydrated como root através de um con job. Os valores DEHYDRATED_USER e DEHYDRATED_GROUP serão usados para executar os scripts. Todas as modificações serão realizadas pelo usuário cadastrado nessa variável e não pelo root. Isso é uma medida de segurança.
- CA contem o tipo de conexão usada pelo Let's Encrypt. Nos comentários do arquivo você verá vários tipos de conexão. Inicialmente usaremos o letsencrypt-test para os ajustes iniciais e testes de comunicação e obtenção de certificados. Uma vez satisfeito as exigência e tudo ter funcionado alteraremos esta para lestencrypt para conseguir os certificados válidos.
- CHALLENGETYPE usará o tipo HTTP de teste, que se comunica com a porta 80 para confimar que um respectivo domínio realmente pertence àquela máquina que realiza o teste.
- WELLKNOWN define um diretório local onde o dehydrated criará 'challenge-tokens' que serão disponibilizados pelo servidor de sites (apache ou nginx) para que o servidor ACME do Let's Encrypt verifique sua existencia naquele domínio e valide os certificados. O servidor ACME repetirá a verificação para cada domínio e subdomínio registrado no arquivo 'domains.txt'.
Nota: A comunicação sempre será feita na posta 80 e se o site fizer redirecionamento automático de HTTP para HTTPS a verificação falhará. - PRIVATE_KEY_RENEW renova a chave privada a cada renovação de certificados. Por padrão ela tem 'yes' como entrada, mas aqui escolhi 'no' por não ter essa necessidade específica.
- CONTACT_EMAIL é usado para criar uma conta com a Let's Encrypt. Este e-mail será usado para avisar caso um certificado esteja próximo de expirar e necessite ser renovado.
- LOCK é o diretório (que precisa ser acessível em escrita para nosso usuário não-root) onde o dehydrat colocará um arquivo de trava (lock) durante a execução dos trabalhos.
- HOOK o caminho para um script que poderá ser executado pelo dehydrated após a criação/renovação de certificados, como por exemplo reiniciar o deamon servidor de site httpd.
Nota: caso este script não exista na sua intalação, coloque um comentário (#) no início desta linha, caso contrário haverão erros durante a execução.
O arquivo "domains.txt" contem uma lista de nomes de dompinio e subdomínio que você quer associar a um certificado SSL. Os certificados contem os nomes dos domínios nos quais serão usados. As vezes recebemos uma mensagem em sites onde "o hostname não pertence ao certificado deste servidor", significando que este certificado SSL foi originalmente criado para outro endereço de domínio.
No nosso caso o arquivo contem apenas um domínio:
www.foo.net
Mas esta linha pode conter qualquer quantidade de endereços separados por espaço, desde que sejam sob o mesmo domínio. Por exemplo "foo.net www.foo.net case.foo.net". Neste exemplo um único certificado será gerado contendo ambos os endereços sob o nome do primeiro listado.
O arquivo "domains.txt" pode gerenciar certificados de vários domínios, cada um em uma linha diferente. Por exemplo, o domínio foo.org em uma linha e um outro domínio foo.net em outra linha. Cada linha corresponde a um certificado SSL diferente para diferentes domínios. E cada linha pode conter múltiplos subdomínios, como foo.org www.foo.org ftp.foo.org.
Para configuração, dois diretórios são muito importantes e precisam ser criados e/ou configurados apropriadamente.
O primeiro é o próprio diretório do dehydrated, /etc/dehydrated. No nosso exemplo o usuário admin executará o comando dehydrated, então as pastas usadas por este precisam ser acessíveis ao usuário admin.
Ou melhor, vamos criar manualmente estes subdiretórios: accounts, certs, chains, var onde o nosso usuário precisa ter acesso de escrita.
Como usuário root, execute:
# mkdir -p /etc/dehydrated/{accounts,certs,chains,var}
# chown admin:wheel /etc/dehydrated/{accounts,certs,chains,var}
Criaremos agora o diretório /etc/local/dehydrated que será onde o dehydrated gerará os arquivos de desafio para o Let's Encrypt. Estes arquivos provam que o servidor realmente tem propriedade do(s) domínio(s) a receber(em) o(s) certificado(os).
Como usuário root, execute:
# mkdir -p /usr/local/dehydrated
# chown admin:wheel /usr/local/dehydrated
Considerações sobre o sudo:
Configuramos o dehydrated para reduzir os previlégios de root afim de usar um usuário comum, criado especialmente e unicamente para executá-lo.
Por este motivo é importante editar uma linha no arquivo /etc/sudoers mudando do padrão:
#root ALL=(ALL) ALL
para:
root ALL=(ALL) ALL
Caso contrário um erro de permissão acontecerá ao se executar o dehydrated.
O que resta agora é configurar o servidor apache (padrão do Slackwware 15.0).
Usando o exemplo do domínio www.foo.net precisamos acrescentar no VirtualHost da porta 80 do arquivo de configuração do apache as seguintes linhas:
Alias /.well-known/acme-challenge /usr/local/dehydrated
<Directory /usr/local/dehydrated>
Options None
AllowOverride None
Require all granted
</Directory>
Isso porque, como dito antes, o dehydrated usará o diretório /etc/local/dehydrated para gerar os arquivos de teste do Let's Encrypt, mas precisamos indicar este direório nas configurações do servidor para que o Let's Encrypt o encontre.
Sendo assim criamos um alias, um "atalho", nas configurações para que o dehydrated tenha acesso à pasta em questão e permitir acesso a este diretório com os comandos na sequência.
Podemos usar o programa de linha de comando lynx para testar a URL (após ter testado a configuração com apachectl -t e reiniciado o serviço com /etc/rc.d/rc.httpd restart).
$ lynx -dump http://www.foo.net/.well-known/acme-challenge/
Forbidden: You don't have permission to access /.well-known/acme-challenge/ on this server.
Apesar do erro, podemos ver que a URL está funcionando, do contrário ao invés de exibir o erro Forbidden apresentaria o erro Not Found.
Com isso nossa configuração do do apache está concluída.
O próximo passo é se certificar de que o servidor esteja habilitado a receber conexões https removendo o comentário do arquivo "/etc/httpd/httpd.conf" na seguinte linha:
# Secure (SSL/TLS) connections
Include /etc/httpd/extra/httpd-ssl.conf
Agora é só testar a configuuração e reiniciar o servidor apache novamente.
Para encerrar só resta indicar no arquivo de configuração do site o local dos certificados.
Criamos mais um VirtualHost para a porta 443 e adicionamos neste setor as seguintes linhas, corrigindo o caminho de pasta de acordo com o nome do domínio.
SSLEngine on
SSLCertificateFile /etc/dehydrated/certs/foo.net/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/foo.net/privkey.pem
SSLCertificateChainFile /etc/dehydrated/certs/foo.net/chain.pem
SSLCACertificatePath /etc/ssl/certs
SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt
Com isso o que resta agora é executar o dehydrated pela primeira vez.
É recomendável usar o CA="letsencrypt-test" no arquivo /etc/dehydrated/config para conferir se a configuração está perfeita, pois o CA="letsencrypt", que gera os certificados oficiais, tem um limite de tentativas e se muitos erros forem encontrados o servidor do Let's Encrypt deixará de emitir certificados para seu usuário durante um curto período, por isso usaremos o servidor de testes primeiro.
Com tudo certo, precisamos apagar manualmente os certificados de teste, alterar o servidor de certificados para só então gerar os certificados válidos.
# rm -r /etc/dehydrated/certs/www.foo.net
# /usr/bin/dehydrated -c
# INFO: Using main config file /etc/dehydrated/config
# INFO: Running /usr/bin/dehydrated as admin/wheel
# INFO: Using main config file /etc/dehydrated/config
Processing www.foo.net
+ Creating new directory /etc/dehydrated/certs/www.foo.net ...
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for www.foo.net
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for www.foo.net authorization...
+ Challenge is valid!
+ Cleaning challenge tokens...
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Done!
Por fim, segue aqui um exemplo de configuração básica para o arquivo de configuração do domínio e servidor de sites do apache:
<VirtualHost *:80>
ServerName www.foo.net
ServerAdmin [email protected]
DocumentRoot /var/www/htdocs/
CustomLog /var/log/httpd/www.foo.net_accesslog combined
ErrorLog /var/log/httpd/www.foo.net_errorlog
# We store the dehydrated info under /usr/local and use an Apache 'Alias'
# to be able to use it for multiple domains. You'd use this snippet:
Alias /.well-known/acme-challenge /usr/local/dehydrated
<Directory /usr/local/dehydrated>
Options None
AllowOverride None
Require all granted
</Directory>
</VirtualHost>
<VirtualHost *:443>
ServerName www.foo.net
ServerAdmin [email protected]
DocumentRoot /var/www/htdocs/
CustomLog /var/log/httpd/www.foo.net_accesslog combined
ErrorLog /var/log/httpd/www.foo.net_errorlog
SSLEngine on
SSLCertificateFile /etc/dehydrated/certs/foo.net/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/foo.net/privkey.pem
SSLCertificateChainFile /etc/dehydrated/certs/foo.net/chain.pem
SSLCACertificatePath /etc/ssl/certs
SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt
<Directory /var/www/htdocs>
Require all granted
AllowOverride All
Options FollowSymLinks
</Directory>
</VirtualHost>
Para mais detalhes e opções, como reiniciar o servidor apache ou pegar um template para o arquivo hook.sh, dê uma olhada no post original do Alien Bob, no qual esta postagem se basea. Há diferenças de configuração entre a postagem dele e a minha, pois ao realizar seu passo a passo percebi que nem tudo era exatamente idêntico. Acredito porque houveram mudanças na versão 15.0, lançada em fevereiro de 2022, após a publicação do Alien Bob, de outubro de 2019. Por isso resolvi fazer esta atualização. Até mesmo para que eu, no futuro, consiga rapidamente colocar outro servidor com Slackwar e dehydrated rodando em pouco tempo.