Proteger o Apache Solr é crucial para impedir a interceptação de dados de busca sensíveis. A configuração padrão opera em HTTP, deixando brechas de segurança, mas é possível implementar criptografia de ponta a ponta usando certificados gratuitos adaptáveis a diferentes níveis de segurança.
Apache Solr SSL é a configuração que permite ao motor de busca operar sob o protocolo HTTPS criptografado (porta 8983). Utilizando a autoridade certificadora Let’s Encrypt, é possível automatizar a emissão de certificados tanto para domínios (validade padrão) quanto para IPs públicos (com rotação acelerada de chaves), garantindo integridade na transmissão de dados.
RESUMO DO TUTORIAL
- Flexibilidade: Escolha entre certificado para Domínio (Padrão) ou IP Público.
- Ciclo de Vida: Opções de renovação padrão (90 dias) ou Alta Segurança (6 dias).
- Modernização: Configuração direta de arquivos PEM, sem necessidade de Java Keystore complexos.
Pré-requisitos do sistema
Para seguir este guia, você precisa de um servidor Linux (Ubuntu ou Debian) com acesso root/sudo. O Apache2 deve estar instalado funcionando como proxy reverso e o Apache Solr já deve estar rodando na porta padrão.
ALERTA: Certifique-se de que as portas 80 e 443 estejam abertas no firewall. O Let’s Encrypt precisa acessá-las para validar a propriedade do servidor.
1. Instale o Certbot e dependências
A ferramenta oficial para gerenciar certificados é o Certbot.
- Atualize a lista de pacotes do sistema:
sudo apt update- Instale o núcleo do Certbot e o plugin Apache:
sudo apt install certbot python3-certbot-apache -y2. Escolha sua estratégia de certificação
Nesta etapa, você deve escolher a rota adequada à sua infraestrutura.
Opção A: Certificado Padrão (Domínio + 90 Dias)
Ideal para servidores de produção padrão com DNS configurado (ex: https://www.google.com/url?sa=E&source=gmail&q=solr.seudominio.com).
- Solicite o certificado automatizado:sudo certbot –apache -d solr.seudominio.com
- Siga as instruções de tela (e-mail e aceite dos termos). O certificado será salvo em
/etc/letsencrypt/live/solr.seudominio.com/.
Opção B: Alta Segurança (IP + Rotação de 6 Dias)
Ideal para ambientes “Zero Trust” ou acesso direto via IP, forçando a troca de chaves a cada 6 dias.
NOTA: O Let’s Encrypt emite certificados válidos por 90 dias. A estratégia de “6 dias” consiste em forçar a renovação via script para garantir que as chaves criptográficas sejam trocadas semanalmente.
- Gere o certificado para o IP (requer parada temporária do Apache se usar porta 80):sudo certbot certonly –standalone -d 1.2.3.4 –preferred-challenges http –pre-hook “systemctl stop apache2” –post-hook “systemctl start apache2”
- Crie o script de automação de ciclo curto:sudo nano /etc/cron.d/certbot-short-cycle
- Cole a regra de agendamento:
# Explicação: Executa as 03:00am. O comando --force-renewal ignora a validade restante e troca a chave.
0 3 */6 * * root certbot renew --force-renewal --deploy-hook "systemctl restart solr apache2"O certificado será salvo em /etc/letsencrypt/live/1.2.3.4/ (ou o nome do seu IP).
3. Configure o SSL no Apache Solr
Agora vamos instruir o Solr a usar os arquivos gerados. As versões modernas (9.x+) leem arquivos PEM diretamente.
- Edite o arquivo de ambiente do Solr (geralmente em /etc/default/solr.in.sh ou /opt/solr/bin/solr.in.sh):sudo nano /etc/default/solr.in.sh
- Adicione as configurações de SSL.Atenção: Substitua CAMINHO_DO_CERTIFICADO pelo caminho gerado no Passo 2 (seja solr.seudominio.com ou seu IP).
# Habilita SSL no Solr
SOLR_SSL_ENABLED=true
# Caminhos para os certificados
SOLR_SSL_KEY_STORE=/etc/letsencrypt/live/CAMINHO_DO_CERTIFICADO/privkey.pem SOLR_SSL_TRUST_STORE=/etc/letsencrypt/live/CAMINHO_DO_CERTIFICADO/fullchain.pem
# Configurações de autenticação (Deixe como false para configuração padrão)
SOLR_SSL_NEED_CLIENT_AUTH=false
SOLR_SSL_WANT_CLIENT_AUTH=false- Ajuste as permissões de leitura (Crucial):O usuário solr precisa ler os arquivos criados pelo root.
# Substitua CAMINHO_DO_CERTIFICADO pelo nome da pasta criada
sudo chown -R root:solr /etc/letsencrypt/live/
sudo chown -R root:solr /etc/letsencrypt/archive/
sudo chmod -R 640 /etc/letsencrypt/live/
sudo chmod -R 640 /etc/letsencrypt/archive/4. Configure o Proxy Reverso Apache2
O Apache2 servirá como a porta de entrada segura.
- Habilite os módulos SSL e Proxy:sudo a2enmod proxy proxy_http ssl rewrite headers
- Crie ou edite o Virtual Host:sudo nano /etc/apache2/sites-available/solr.conf
- Insira a configuração, ajustando o
ServerNamepara seu Domínio ou IP:
<VirtualHost *:443>
# Use seu Domínio ou IP aqui
ServerName solr.seudominio.com
ErrorLog ${APACHE_LOG_DIR}/solr_error.log
CustomLog ${APACHE_LOG_DIR}/solr_access.log combined
SSLEngine on
# Ajuste o caminho conforme o passo 2
SSLCertificateFile /etc/letsencrypt/live/CAMINHO_DO_CERTIFICADO/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/CAMINHO_DO_CERTIFICADO/privkey.pem
# Proxy para o Solr (agora via HTTPS)
ProxyPreserveHost On
ProxyPass /solr https://localhost:8983/solr
ProxyPassReverse /solr https://localhost:8983/solr
RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>- Ative e reinicie:sudo a2ensite solr.confsudo systemctl restart apache2
5. Validação final
Para aplicar as mudanças no backend, reinicie o Solr.
- Reinicie o serviço:sudo systemctl restart solr
- Verifique o status:sudo systemctl status solr (Se falhar, verifique se o caminho dos certificados no solr.in.sh está correto e se as permissões chmod foram aplicadas).
- Teste no navegador: Acesse https://seu-ip-ou-dominio/solr.
Solução de problemas comuns
Solr não inicia após ativar SSL
Geralmente é um problema de permissão. O Solr roda com usuário restrito e o Let’s Encrypt cria arquivos como root.
- Solução: Reexecute os comandos de
chownechmodlistados no final do Passo 3.
Erro 503 ou 502 Bad Gateway
Ocorre se o Apache tenta conectar via HTTPS mas o Solr ainda está em HTTP (ou vice-versa).
- Solução: Verifique se
SOLR_SSL_ENABLED=trueestá ativo nosolr.in.she se a linhaProxyPassno Apache aponta parahttps://.
Renovação de IP falhando
O Let’s Encrypt exige que o IP seja público e acessível na porta 80.
- Solução: Se você escolheu a Opção B, verifique se nenhum firewall está bloqueando o tráfego de entrada na porta 80 durante a renovação.