Tutorial SSL com Lets Encrypt: Certificado gratuito e homologado para lojas virtuais

Aprenda neste tutorial como configurar certificados SSL válidos usando a tecnologia Let’s Encrypt, que permite emitir certificações para sites que exigem encriptação SSL usando o protocolo https para navegação, como por exemplo lojas virtuais ou páginas de login.

Let’s Encrypt é um projeto de esforço mundial que visa tornar a internet mais segura e que tem o apoio de grandes empresas do setor de tecnologia. A emissão e a renovação dos certificados são gratuitas e “lifetime”, ou seja, você nunca irá precisar pagar por ele o resto da vida do domínio.

Seguindo os meus tutoriais você deve ter notado que ao navegar pelas páginas  do painel de controle, phpMyAdmin e Webmail usando https o acesso exibe uma aviso dizendo que o certificado não é válido. Isso ocorre porque ao instalar o ISPConfig e os serviços emitimos um certificado genérico a partir do próprio servidor, sem a devida validação por órgãos competentes.

Com a instalação do Let’s Encrypt e a devida configuração do bloco de diretivas no NginX podemos adicionar ao servidor e aos sites certificados válidos, e que inclusive são homologados para uso em lojas virtuais que conectam-se a Cielo por exemplo.

*Eu já utilizo o Let’s Encrypt por aproximadamente um ano instalando em servidores de sites parceiros e clientes para lojas Magento, Opencart e Prestashop, além de sites WordPress que dependem de login com https. Até hoje não tivemos problema algum com ele.

Certificado SSL gratuito com Let’s Encrypt:

* Esta documentação pode servir como base para implementação do Let’s Encrypt em servidores com Apache e outras distros Linux diferentes de Debian 8, porém é altamente recomendável seguir nosso tutorial  de Servidor Linux VPS: Debian 8 Jessie com ISPConfig 3 e NginX + Servidor de Emails, clique aqui e aprenda como instalar.

Instalação do certbot

O nosso tutorial de Debian 8 (ver link acima) já tem os comandos para instalar e ativar o certbot (app usado para instalar e gerenciar os certificados da Let’s Encrypt no servidor). Mas caso você não tenha ele instalado siga os procedimentos abaixo:

*Execute os comandos para instalação e configuração dos certificados logado no servidor com o superusuário root.

Adicione o repositório backports do Debian, atualize a lista de pacotes e instale o aplicativo.

Edite o arquivo /etc/apt/sources.list e verifique se ao final há uma linha parecida com esta, se não houver adicione:

deb http://ftp.debian.org/debian jessie-backports main

Em seguida atualize o repositório e instale o Let’s Encrypt:

> apt-get update

> apt-get -y install -t jessie-backports certbot

*Mas somente execute este primeiro passo caso não tenha o certbot instalado ainda.

2 Passo complementar: Prevenindo Logjam attack

Para prevenir este tipo de ataque ao SSL pode-se configurar um parâmetro nas diretivas do site gerando uma chave de criptografia adicional ao certificado. Execute os comandos abaixo. *Estes comandos só serão necessários uma única vez para o servidor e a encriptação da chave poderá demorar até 3 minutos em alguns casos.

> cd /etc/ssl/private
> openssl dhparam -out dhparams.pem 2048
> chmod 600 dhparams.pem
3 Arquivo com o bloco NginX para servir páginas do painel, phpMyAdmin e Webmail do servidor pelo FQDN (hostname)

Se você seguiu atentamente o meu tutorial provavelmente criou o nome do servidor (hostname) com uma URL válida (FQDN). Por exemplo, ao fazer o deploy do VPS digitou no hostname uma URL válida como esta: server1.SEUDOMINIO.COM e adicionou o subdominio “server1” nos registros da tabela DNS do SEUDOMINIO.COM. Caso não tenha feito isso sempre há tempo para recomeçar da maneira correta.

Considerando que o seu FQDN (URL de acesso ao servidor) seja server1.SEUDOMINIO.COM, crie um novo arquivo no diretório /etc/nginx/sites-available com o nome de vps.vhost e cole as diretivas abaixo dentro dele, substituindo server1.SEUDOMINIO.COM pelo FQDN do servidor:

server {
 listen 80;

 #COMENTAR as linhas SSL para validar o certificado LetsEncrypt e liberar elas apos a emissao
 # listen 443 ssl;
 # ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 # ssl_certificate /etc/letsencrypt/live/server1.SEUDOMINIO.COM/cert.pem;
 # ssl_certificate_key /etc/letsencrypt/live/server1.SEUDOMINIO.COM/privkey.pem;
 # ssl_trusted_certificate /etc/letsencrypt/live/server1.SEUDOMINIO.COM/fullchain.pem;
 # ssl_stapling on;
 # ssl_stapling_verify on;
 # ssl_dhparam /etc/ssl/private/dhparams.pem;
 # ssl_session_cache shared:ssl_session_cache:10m;
 # ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

 server_name server1.SEUDOMINIO.COM;
 root /usr/local/ispconfig/interface/web/;
 client_max_body_size 100M;

 location / {
 index index.php index.html;
 }

 # serve static files directly
 location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt)$ {
 access_log off;
 }

 location ~ \.php$ {
 try_files $uri =404;
 include /etc/nginx/fastcgi_params;
 fastcgi_pass unix:/var/lib/php5-fpm/ispconfig.sock;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 #fastcgi_param PATH_INFO $fastcgi_script_name;
 fastcgi_buffer_size 128k;
 fastcgi_buffers 256 4k;
 fastcgi_busy_buffers_size 256k;
 fastcgi_temp_file_write_size 256k;
 }

 location ~ /\. {
 deny all;
 }
 location ^~ /.well-known/acme-challenge/ {
 default_type text/plain;
 }

 location /phpmyadmin {
 root /usr/share/;
 index index.php index.html index.htm;
 location ~ ^/phpmyadmin/(.+\.php)$ {
 try_files $uri =404;
 root /usr/share/;
 fastcgi_param QUERY_STRING $query_string;
 fastcgi_param REQUEST_METHOD $request_method;
 fastcgi_param CONTENT_TYPE $content_type;
 fastcgi_param CONTENT_LENGTH $content_length;

 fastcgi_param SCRIPT_FILENAME $request_filename;
 fastcgi_param SCRIPT_NAME $fastcgi_script_name;
 fastcgi_param REQUEST_URI $request_uri;
 fastcgi_param DOCUMENT_URI $document_uri;
 fastcgi_param DOCUMENT_ROOT $document_root;
 fastcgi_param SERVER_PROTOCOL $server_protocol;

 fastcgi_param GATEWAY_INTERFACE CGI/1.1;
 fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

 fastcgi_param REMOTE_ADDR $remote_addr;
 fastcgi_param REMOTE_PORT $remote_port;
 fastcgi_param SERVER_ADDR $server_addr;
 fastcgi_param SERVER_PORT $server_port;
 fastcgi_param SERVER_NAME $server_name;

 fastcgi_param HTTPS $https;

 # PHP only, required if PHP was built with --enable-force-cgi-redirect
 fastcgi_param REDIRECT_STATUS 200;
 # To access phpMyAdmin, the default user (like www-data on Debian/Ubuntu) must be used
 #fastcgi_pass 127.0.0.1:9000;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_buffer_size 128k;
 fastcgi_buffers 256 4k;
 fastcgi_busy_buffers_size 256k;
 fastcgi_temp_file_write_size 256k;
 fastcgi_read_timeout 1200;
 }
 location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
 root /usr/share/;
 }
 }
 location /phpMyAdmin {
 rewrite ^/* /phpmyadmin last;
 }

 location /roundcube {
 root /var/lib/;
 index index.php index.html index.htm;
 location ~ ^/roundcube/(.+\.php)$ {
 try_files $uri =404;
 root /var/lib/;
 include /etc/nginx/fastcgi_params;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_buffer_size 128k;
 fastcgi_buffers 256 4k;
 fastcgi_busy_buffers_size 256k;
 fastcgi_temp_file_write_size 256k;
 }
 location ~* ^/roundcube/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
 root /var/lib/;
 }
 location ~* /.svn/ {
 deny all;
 }
 location ~* /README|INSTALL|LICENSE|SQL|bin|CHANGELOG$ {
 deny all;
 }
 }
 location /webmail {
 rewrite ^/* /roundcube last;
 }
}

Salve o arquivo, que deverá ser /etc/nginx/sites-available/vps.vhost, e execute os comandos abaixo:

> ln -s /etc/nginx/sites-available/vps.vhost /etc/nginx/sites-enabled/vps.vhost
> /etc/init.d/nginx restart

Após fazermos isso note que já podemos acessar o painel do ISPConfig pela URL http://server1.SEUDOMINIO.COM, o phpMyAdmin pela URL http://server1.SEUDOMINIO.COM/phpmyadmin e o Roundcube pela URL http://server1.SEUDOMINIO.COM/webmail. Mas ainda falta emitir o certificado para que seja possível acessar as mesmas URLs com https.

4 Emissão do certificado SSL para o FQDN do servidor

Agora que já temos uma URL válida para acessar o servidor podemos solicitar a emissão do certificado SSL para ela. *O emissor de certificados da Let’s Encrypt (ACME) irá verificar se a URL existe e se tem um caminho reverso para a origem, por isso a necessidade de configurar uma URL válida.

*A ACME não permite a emissão de certificados “wildcards” (subdomínios múltiplos), então para cada subdomínio será necessário um novo pedido de emissão. A única exceção é o “www”.

Comando para emitir o certificado para o FQDN de um servidor com ISPConfig e NginX, note o caminho de instalação dos scripts web da página. Substitua o FQDN pelo do seu servidor e [email protected] por um email válido, pois caso haja problemas com o certificado você será notificado:

> certbot certonly --agree-tos --renew-by-default --webroot --email [email protected] -w /usr/local/ispconfig/interface/web -d SERVER1.SEUDOMINIO.COM

Para saber se o certificado foi emitido corretamente uma mensagem de “Congratulations” será exibida indicando o caminho que o certificado foi instalado e que deverá ser /etc/letsencrypt/live/. *Para verificar pode-se também listar o diretório e ver se há um subdiretório com o domínio do site.

Após isso só precisamos descomentar as linhas do certificado no arquivo de diretivas (retirando as “#hashtags das linhas 5 a 14 do vps.vhost), salvar o arquivo e reiniciar o NginX:

> /etc/init.d/nginx restart

Agora o ISPConfig, phpMyAdmin e Webmail já podem ser acessados com https sem dar erro de certificado.

5 Let’s Encrypt para os sites

Muito bem. Agora que já temos o certbot instalado e o método de uso pronto, já podemos emitir certificados para todos os sites no mesmo servidor. O ISPConfig facilita a configuração das diretivas NginX para os sites, irei mostrar abaixo como fazer isso usando ele, mas caso não tenha ISPConfig então verifique na configuração do seu painel como fazer.

Acesse o painel do ISPConfig e selecione o site que deseja emitir o certificado. Clique na aba “Options” do site e adicione as diretivas abaixo ao final das demais diretivas NginX que lá estão:

location ^~ /.well-known/acme-challenge/ {
   default_type text/plain;
}

Clique em salvar e aguarde alguns minutos. Em seguida execute o comando abaixo logado no servidor como superusuário root e substituindo os textos em vermelho pelo email e domínio corretos:

*Note que agora o caminho web para o site é diferente do anterior para o FQDN, nesta emissão você deverá digitar onde cada site está instalado. Para sites adicionados ao ISPConfig basta trocar DOMINIO001.COM pelo seu domínio de site.

*E note que adicionamos um novo parâmetro ao comando para que a emissão seja feita também para o “www”.

> certbot certonly --agree-tos --renew-by-default --webroot --email [email protected] -w /var/www/DOMINIO001.COM/web -d DOMINIO001.COM -d www.DOMINIO001.COM

E para finalizar você deverá colar as diretivas NginX para cada site, na caixa de diretivas NginX da aba “Options” do site. Mas desta vez cole-as no início, antes de todas as outras diretivas lá.

*Lembre-se de substituir o DOMINIO.

listen 443 ssl;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /etc/letsencrypt/live/DOMINIO001.COM/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/DOMINIO001.COM/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/DOMINIO001.COM/fullchain.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_dhparam /etc/ssl/private/dhparams.pem;
ssl_session_cache shared:ssl_session_cache:10m;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
6 Agendamento do certbot no CRON 

Um último passo irá assegurar que o servidor nunca fique sem o certificado de segurança. Na documentação do Let’s Encrypt esta informação não é clara por isso é bom prevenir. E há vários relatos nos fóruns deles dizendo que é necessário reiniciar o NginX após a reemissão do certificado.

O certificado da Let’s Encrypt é lifetime porém a reemissão e revalidação do mesmo é obrigatória a cada 4 meses em média.

Edite o CRON:

> crontab -e

E cole as seguintes linhas ao final:

15 23 * * * /usr/bin/certbot renew -q
0 5 * * * /etc/init.d/php5-fpm restart > /dev/null
0 5 * * * /etc/init.d/nginx restart > /dev/null

Salve as tarefas (para sair do editor salvando tecle CTRL+X e y).

* OBSERVAÇÃO em 19/05/2017:

Ao emitir o certificado talvez ocorra o erro abaixo:

Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
ClientError: <Response [504]>

O motivo do erro 504 na maioria das vezes é: ou problema de conexão com a Lets Encrypt, ou problema nos servidores deles. Verifique o status do serviço de emissão dos certificados neste link: https://letsencrypt.status.io/

NOTAS:

Domínios com a tabela DNS configurada na CloudFlare e que estejam com a nuvem ativada (laranja) é importante verificar na aba “Crypto” se o certificado está ligado. Na maioria dos casos essa opção deverá estar selecionada como “Flexible” mas para lojas virtuais é recomendável deixar como “Full Strict“.

Mesmo com as diretivas acima configuradas note que o https das páginas não está “forçado”, ou seja, ainda é possível acessar o site com http. Para sites WordPress existe um plugin que resolve isso chamado Really Simple SSL. Se quiser encontrá-lo mais facilmente entre no painel admin do WordPress e clique em Adicionar Novo Plugin e na aba Favoritos digite “fatorbinario“, isso irá exibir todos os plugins que marquei como favoritos no WordPress.org. Instale o plugin e ative-o. Por último será exibida uma mensagem no topo da tela com um botão azul de “Go ahead, activate SSL!“, clique nele e pronto.

Para saber como forçar o SSL em todas as páginas usando outros CMS ou até mesmo para sites em PHP deixe um comentário.

Gerenciamento em infraestrutura de Servidores Cloud VPS e Dedicados. Planos mensais acessíveis e consultoria diferenciada para agências de marketing. Envie um email para [email protected] e solicite uma análise gratuita!

728x90a
  • Dan El Pierre Rezende

    Mais um tutorial muito rico de informação importante, parabéns!

  • Lucas Lennon

    Olá Luis, que maravilha de tutorial.

    Como poderia fazer para forçar o https site em PHP?

  • Coloque estas diretivas logo abaixo das linhas que apontam para o certificado (passo 5):

    if ($scheme != “https”) {
    rewrite ^ https://$host$request_uri permanent;
    }

  • Lucas Lennon

    Muito obrigado deu certinho.

  • André

    +1 vez ótimo tudo. Consigo usar este ENCRYPT com Tutorial Webmin com Nginx, Firewall, Postfix e phpMyAdmin?

  • Acredito que sim. Mas o Webmin tem um webserver próprio e teria que configurar nele.

    A emissão do SSL é sossegada, pode-se inclusive usar o Lets Encrypt para substituir os certificados de SMTP e FTP.

  • André

    🙂 ótimo testar aqui. Vc tem alguma vídeo aula ou curso online?

  • Tenho um video tutorial do Debian 7 no Youtube.

  • Rafael Silva

    Olá Luis, muito bom o tutorial, gostaria de tirar uma dúvida como posso redirecionar o site sem www para www? Já tentei ver alguns exemplos na internet mais não consigo. Sei que pelo ISPCONFIG tem como fazer isto, mas tenho outro VPS que não utilizo o ISPCONFIG e alguns sites por padrão estão indexados com www. Com php sei fazer isto mas tem alguma forma de fazer com diretiva no NGINX?

  • O caminho da requisição URL é o seguinte:
    – Tabela DNS: lá precisa existir as 2 entradas, com e sem www
    – Servidor (NginX) precisa ter na variável “server_name” o dominio com e sem www
    – No CMS (WordPress) configurar a URL do site com OU sem www, escolhe uma delas e confirma.

    Se o site não foi desenvolvido em CMS (sites PHP), então deve-se redirecionar isto no NginX. Uma maneira fácil de fazer isso é assim:
    http://stackoverflow.com/questions/7947030/nginx-no-www-to-www-and-www-to-no-www

    No exemplo tem como fazer via “server” block ou rewrite.

  • Rafael Oliveira

    Cara, seguei teu tutorial todo umas 3 vezes hoje, tinha feito um outro servidor com um script que já instalava o php7 e dava a opção de não ficar com servidor de email, era oque eu queria pois já conhecia a Zoho, só que o cara não deu seguimento aí eu não conseguia enviar email pelo sistema nem pelo Php mail(), nem pelo SMTP (), como ele não explicou como fazer, tentei alterar o outro servidor mas tava achando mais fácil fazer novamente, foi oque eu fiz até solicitei pra a DigitalOcean liberar a porta 25 mas depois deletei e refiz o servidor.

    Só tive um problema que não consegui resolver Luis, não consegui o certificado para o meu servidor, criei o droplet como cp.meudominio.com, e ele está no dns da CloudFlare como uma entrada do tipo A que aponta para o ip, 187.877.877.87 mas dá falha.

    Na mensagem de erro, inclusive ele manda eu verificar se tem o registro A no DNS correto.

    O meu dominio ali eu alterei, só por privacidade mesmo estava o dominio correto.

    Failed authorization procedure. cp.viptvbr.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://cp.MEUDOMINIO.com/.well-known/acme-challenge/m5c2tz-AQLZuHNVgb7jHBqdYSQ3UAvoP9RkERghGnr8: “DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN
    “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”

    IMPORTANT NOTES:
    – The following errors were reported by the server:

    Domain: cp.MEUDOMINIO.com
    Type: unauthorized
    Detail: Invalid response from
    http://cp.MEUDOMINIO.com/.well-known/acme-challenge/m5c2tz-AQLZuHNVgb7jHBqdYSQ3UAvoP9RkERghGnr8:
    DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN
    “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address.

    Para o domínio mesmo eu consegui emitir o certificado, to felizão d+ já com o resultado obrigado pelos tutoriais já tá até na whitelist do uBlock ♥

  • Mesmo que você não queira o servidor de email ele pode ser necessário para enviar mensagens de sistema e, mesmo se for via relay, terá que configurá-lo. O cara criou um script sem muita noção do que estava fazendo. Quanto ao PHP 7, o Debian 9 já terá suporte nativo a ele e provavelmente o ISPConfig também.

    Há como enviar emails sem nem mesmo liberar a porta SMTP mas não publiquei o tutorial para isso, só instalo para clientes e revendas de parceiros.

    Vejo ali que você instalou o Apache ao invés de NginX, você poderá se arrepender mais tarde. E este artigo cobre a configuração do Lets Encrypt para NginX, no Apache tem que instalar uma outra versão do certbot própria do Apache. Mas mesmo assim, o seu problema deve estar sendo de permissão para conseguir criar a pasta “.well-known” para o bloco de diretivas da URL que deseja o SSL.

  • Rafael Oliveira

    Estou usando o NginX mesmo ou era para estar, o Apache insistia em aparecer ai refiz todo o tutorial a parte de desativar o apache, mas ele aparecia a página html ainda, só depois ficou a página padrão do ISPConfig quando criei o diretório do site no painel.

    O meu problema foi com o certificado para o painel, ele está com o auto-assinado talvez por isso nào conseguiu autenticar? Mas enfim ele não é tão importante, só pretendo um site de uso pessoal mesmo por enquanto, mas o certificado do www tá funcionando perfeitamente.

    Luís eu estou usando o WHMCS, não consegui de forma alguma (Phpmail ou SMTP) enviar os emails mesmo com o relay pela Zoho, vou refazer e tentar colocar pela SparkPost eu vi que pelo o relay eu nem preciso solicitar pra liberar a porta 25, já que vai ter o túnel certo? Só conseguir consertar isso aí vai ficar 100% para o que eu quero.

    Obrigado mais uma vez, vou tentar resolver o problema. Um bom feriado

  • Olá Luis, me confirme uma informação, segui seu tutorial de instalação do ISPConig e no meu consegui utilizar o LetsEncript automaticamente sem precisar fazer o que esta neste tutorial… Esta certo isso, ele já vem nativo no ISPConfig (ultima versão) ?

  • Instalou com Apache?

  • Rafael Oliveira

    Quando instala ele baixa o certbot já, no tutorial ele fala sobre isso ai se já tiver baixado não precisa baixar novamente e na verdade o correto seria pra conseguir gerar pelo o painel do ISP.

  • Instalei um servidor agora a tarde e está tudo 100% conforme o tutorial.

  • Opa… Obrigado pela resposta. Instalei com o NGINX. Esta funcionando perfeitamente.

  • Rafael Oliveira de Santana

    @fatorbinario:disqus Eu incomodando você novamente….Em outro tópico, eu informei que não conseguia acessar o Phpmyadmin.
    Eu fiz a configuração agora….mas ainda não consegui abrir o mesmo. O que eu ainda preciso ver ou que fiz de errado?

  • Reveja a instalação, te garanto que está tudo funcionando.

  • Rafael Oliveira de Santana

    Esta sim…eu tava viajando mesmo…rs Um pouco lento…mas vejo isso depois

  • Rafael Oliveira de Santana

    Segui os passos acima, na parte de gerar o certbot:
    certbot certonly –agree-tos –renew-by-default –webroot –email [email protected] -w /usr/local/ispconfig/interface/web -d server.meusite.com.br
    […]
    pkg_resources.DistributionNotFound: The ‘ndg-httpsclient’ distribution was not found and is required by request
    Dando uma pesquisada, achei a solução…e por causa desse pacote que não foi instalado (sei la porque)
    Solução: rodar o comando “sudo apt-get install python-ndg-httpsclient -t jessie-backports.” Fonte: https://community.letsencrypt.org/t/the-ndg-httpsclient-distribution-was-not-found-error/33084

    Agora….olha a mensagem que mudou….

    Failed authorization procedure. server.meusite.com.br (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for server.meusite,com.br

    IMPORTANT NOTES:
    – If you lose your account credentials, you can recover through
    e-mails sent to [email protected].
    – The following errors were reported by the server:

    Domain: server.meusite.com.br
    Type: connection
    Detail: DNS problem: NXDOMAIN looking up A for
    server.rafaelsantana.net.br

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.
    – Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal

  • Tem que colocar as regras para o diretório “well-known” senão dá nisso ai.

  • Rafael Oliveira de Santana

    Apaguei o meusite.com.br do ispconfig. Vou tentar gerar denovo para vps!

  • Caio Hodos

    Luis, tudo bem?

    Você já presenciou ou sabe de algo que ativando o Let’s Encrypt dobre o TTFB e Response Time ou até aumente o consumo de processamento do servidor? Em dois sites e servidores diferentes que ativei o HTTPS estou sofrendo com isso.

    Um detalhe, estou utilizando o ISPConfig 3.1, então fiz toda a ativação pelo painel do ISP. O DNS é via CloudFlare com SSL Full (strict) nele. Alguma dica?

    Muito obrigado!

  • Sim Caio, com o SSL no site as requisições demoram o dobro sim.. Eu até tinha aqui um link da CloudFlare que mostrava isso em detalhes mas não consegui encontrar agora.

    É assim mesmo, você ganha confiabilidade no site mas perde em tempo de carregamento.

  • Rafael Oliveira de Santana

    Eu ainda não fiz o passo 5, para o dominio meusite.com.br Eu executei o passo 4, que e para o servidor server.meusite.com.br esse deu o erro.

  • A URL tem que existir e estar propagada. E você fez com NginX ou Apache?

  • Rafael Oliveira de Santana

    Pelo Nginx.
    Passo5: Eu deletei o site pelo painel e criei denovo. Fui em Mail, gerei o DKIM, e gerei aquelas chaves tudo pelo painel. Depois de ter criado novamente o meusite.com.br, cliquei na primeira página as opções SSL, Lets Encrypt, na outra aba, Force HTTP to HTTPS, e na ultima Nginx Directives, os snippets de SSL. E olha que dahora, ele gerou o certificado sozinho (esta apenas a página default). Que emoção! rs Mas gerou para www e não-www. Só preciso ver a questão do www, direcionar para não-www, para ter uma url única (preciso por o snippet especifico no “nginx directive” ou na aba redirect a regra?).

    Vou tentar então o passo 4, para gerar o certificado pro servidor server.meusite.com.br e te falo.

  • Rafael Oliveira de Santana

    A regra de redirect www para nao-www na aba “Redirect” esta certa? http://imgur.com/xtoDRiD Peguei as regras do site oficial https://www.nginx.com/blog/creating-nginx-rewrite-rules/ Ou estou colocando em lugar errado?

    A aba “Options” esta certinha eu acho http://imgur.com/g3ibdce

  • Nunca precisei fazer isso na aba Redirect..

    Se o site for WordPress você só precisa ativar o “www” na aba Geral do site, criar a entrada www na tabela DNS e dentro do WordPress dizer lá nas configurações do site que quer com www.

  • Rafael Oliveira de Santana

    Ah blz….rs Não preciso por em lugar nenhum aquele código la ne?
    “Redirect Type: Redirect” e “SEO Redirect: http://www.domain.tld => domain.tld”

    Por enquanto, so esta com a pagina default mesmo: rafaelsantana.net.br
    Então, porque com isso não funciona. Coisa tão simples e eu apanhando aqui 🙁

    Eu criei os snippets la, conforme viu na imagem la na aba Options

  • Samuel Batista

    Luis eu to usando cloudflare em dois sites que eu tenho, tera algum problema se eu fizer este tutorial agora ?

  • Sim. Meio que não tem nada a ver uma coisa com outra..
    Só precisa atentar para aquele lance da nuvem, se estiver ligada configurar o Crypto como Full.

  • Samuel Batista

    Luis fiquei com receio do passo 1, como faço pra conferir se o certbot ja foi instalado?

    Meu servidor ta tão lindo e perfeito graças a você é claro, que tenho medo até de entrar nele e fazer alguma besteira rsrs

  • Se você tentar instalar um pacote que já exista vai aparecer uma tentativa de instalar seguida de “nada a se fazer”, ou seja só avisará que já existe no sistema.
    Uma segunda opção é digitar “certbot” e ver se o comando já existe.
    Ou ainda, use o apt-get para exibir informações sobre o pacote com o comando: “apt-cache policy certbot”

  • Samuel Batista

    Vlw Luis!!!
    eu já tenho ele instalado certbot pois apareceu informações com “apt-cache policy certbot”, então vou pular para o passo 2 como vc diz no final do passo 1

    Mais uma vez Obrigado!

  • @[email protected]:disqus , boa tarde!

    Possui alguma configuração que força o http para https para os servidores?. A url dos servidores, so funcionam o SSL se eu colocar https antes.

    Obrigado.

  • So o site for WordPress tem vários plugins para isso. Se for Magento tem como configurar a URL diretamente no admin. Mas se for site PHP ou que não seja CMS, é só adicionar estas diretivas:

    if ($scheme != “https”) {
    rewrite ^ https://$host$request_uri permanent;
    }

  • Otimo, so que é o proprio ispconfig, phpmyadmin e roundcube.

  • @fatorbinario:disqus , boa noite!

    Fiz a configuração, só que no ispconfig, quando digito a url ele não força o https, tem alguma sugestão?.

  • Coloque estas 2 diretivas depois daquelas de certificado no vps.vhost:

    # Redireciona para HTTPS se accessado com HTTP
    add_header Strict-Transport-Security “max-age=31536000; includeSubdomains”;
    error_page 497 https://$host$request_uri;

  • Obriigado Luis, portanto não foi com exito. Tem alguma outra sugestão?.

  • Ola @fatorbinario:disqus ,

    Estou tentando incluir a cron de um sistema, portanto ele informa apenas esse comando php -q /—–/—-/—-/—–/—-/—–/crons/cron.php, ja incluir esse comando no ispconfig, ja configurei manualmente, contudo ele não valida. Poderia me ajudar?.

  • Veja lá no tutorial de Mautic que tem exemplos de como incluir CRONs no ISPConfig. Se já fez certo e não funcionou é porque o script tá bugado ou algo do tipo.

  • Daniel Azeredo

    Boa noite, Eu fiz todo o tutorial desde o início. Muito bom!

    Mas estou com um problema com o https.

    Quando eu acesso com http://meusite.com.br ele não é redirecionado para https://meusite.com.br. Então fiz esta configuração que vc passou. Agora ele redireciona, mas a pagina não abre.

  • Se o site for WordPress tem plugin que força o https para ele. Se não for usa as diretivas. E se a página não abre me diga o que aparece..

  • Daniel Azeredo

    Segue a mensagem de erro:

    imagem: https://ibb.co/g4DcV5

    The page isn’t redirecting properly

    Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

    This problem can sometimes be caused by disabling or refusing to accept cookies.

  • Isso acontece quando você força o certificado em 2 lugares diferentes. Por exemplo, se você usa um plugin no WordPress que força SSL ou se tem uma loja Magento que força no arquivo de configuração então não pode usar as diretivas no NginX forçando.

    E se a tabela DNS está na CloudFlare com as nuvens laranjas ativadas então o Crypto dela tem que estar como Full ou Full Strict.

  • Daniel Azeredo

    Acertei no cloudflare.

    E uma coisa que eu não tinha informado. O host do meu vps é vps1.meusite.com.br. Eu tinha colocado as configuração do certificado também nas diretivas nginx do site meusite.com.br. Por este motivo estava dando problema.

    Depois que eu removi, funcionou o redirect para o site e para o webmail. MAs o vps1.meu site.com.br continua como http. Eu coloquei a diretiva abaivo no vps.vhost mas maesmo assim ele não funcionou.

    Você sabe o que eu posso fazer mais?

  • Com certeza ainda está errando, tem tudo no tutorial, eu mesmo sigo ele quando crio servidores e olha que somente este mês foram aproximadamente 40 servidores.

  • Leandro Aguiar

    Olá @Luis FatorBinario:disqus ,

    Primeiramente parabéns pelos tutoriais!
    Eu
    que nunca tive experiência com servidores consegui configurar 3 quase
    sem problemas nos últimos 3 meses seguindo suas palavras.
    Dessas 3
    experiências, 2 foram em máquinas virtuais na minha própria casa para
    aprender antes de colocar efetivamente um servidor em produção.
    Nos
    dois teste eu não emiti um certificado com o Let’s Encrypt. Já na
    terceira experiência (o servidor em produção), eu emiti os dois
    certificados conforme seu tutorial.
    O certificado para o meu domínio (ex.: DOMINIO.COM) funciona perfeitamente!
    Já o certificado para o FDQN do servidor (ex.: SERVER.DOMINIO.COM) apresenta um comportamento diferente do esperado:

    Ao acessar o Roundcube (SERVER.DOMINIO.COM/WEBMAIL) tudo funciona como
    esperado. Conexão https com uso do certificado emitido para o FDQN;

    Ao acessar o ISPConfig (SERVER.DOMINIO.COM:8080) o certificado emitido
    para o FDQN não é utilizado, mas sim o certificado emitido ao instalar o
    ISPConfig;
    – Ao acessar o PHPMyAdmin (SERVER.DOMINIO.COM:8081/PHPMYADMIN) nenhum certificado é utilizado. A conexão é feita via http;

    Ao acessar o PHPMyAdmin pelo endereço https
    (https://SERVER.DOMINIO.COM:8081/PHPMYADMIN) o navegador apresenta o
    seguinte erro:

    “Falha na conexão segura
    An error occurred
    during a connection to server.dominio.com:8081. SSL received a record
    that exceeded the maximum permissible length. Error code:
    SSL_ERROR_RX_RECORD_TOO_LONG”

    Quando essa última condição acontece, o log de acesso do Nginx mostra a seguinte informação:

    191.217.66.153
    – – [30/Jun/2017:19:50:29 -0300]
    “x16x03x01x00xC8x01x00x00xC4x03x03x82xBDxA3x91xA2x8BxECXQxxBCx0Ex9CxB2x03xB6x87x98{xE5xC9xF5xD3$xA3xF8xE2&kxD6;xCEx00x00x1ExC0+xC0/xCCxA9xCCxA8xC0,xC00xC0”
    400 166 “-” “-”

    Após revisar cuidadosamente todo o passo a passo
    do seu tutorial e pesquisar por alguns dias pela internet, não consegui
    ainda encontrar um motivo pelo qual esse comportamento tem acontecido e
    nem descobri ainda como colocar tudo para funcionar como deveria.
    Como
    o acesso ao ISPConfig é feito pelo menos com o uso de um certificado
    (mesmo que seja um “provisório”), eu estou um pouco mais tranquilo em
    acessá-lo. Mas a conexão ao PHPMyAdmin sem nenhum certificado SSL não é
    adequada e por isso não o acessei até hoje (mesmo após 30 dias do
    servidor de pé).

    Você já se deparou com este problema ou pode me indicar algum caminho para que eu possa seguir?

  • Acertou quase tudo só esqueceu de ler a parte do tutorial acima onde eu mostro que após instalar o SSL Lets Encrypt para o FQDN todas as URLs de administração permitem acesso sem especificar as portas. Por exemplo, você tentou acessar https://dominio.com.br:8080. O 8080 não é mais necessário pois o vps.vhost foi configurado para usar as portas 80 e 443 somente.

  • Leandro Aguiar

    Luis, pelo jeito não revisei o passo a passo do tutorial tão cuidadosamente quanto eu imaginei. Obrigado pelo esclarecimento!

    Como o acesso se dá sem a necessidade de apontar portas (ou seja, pelas portas 80 e 443), você acha relevante evitar o acesso pela porta 80, mantendo apenas o acesso via conexão com SSL?
    Pergunto isso pois notei nos logs de acesso do Nginx que o PHPMyAdmin é um alvo rotineiro de tentativas de login e essas tentativas vêm sempre pela porta 80.
    Até o momento ninguém conseguiu entrar devido as seguintes medidas de segurança:
    – Bloqueio do acesso aos sites via endereço IP (conforme orientado por você no tutorial);
    – Criação e uso de um filtro específico no fail2ban para barrar por algumas horas o atacante;
    – Uso de uma senha forte.

    A primeira e a terceira medidas eu já utilizo desde o primeiro dia, já a segunda eu criei a pouco tempo. Antes de implementar esse filtro cheguei a registrar mais de 1200 tentativas em 24h. Hoje registro entre 15 e 20.

  • Acesse o Strong Password Generator (https://strongpasswordgenerator.com/) e gere senhas de 15 caracteres. Mesmo que alguém continue tentando acessar levará algumas décadas para conseguir.

  • Rafael Oliveira de Santana

    Eu fiz um teste e rodei esses comandos para colocar o roundcube como 8082, segundo esse seu outro tutorial https://fatorbinario.com/comunidade/topico/como-acessar-o-roundcube-e-o-policyd-pelo-ip-no-servidor-com-ispconfig/
    Sera que tem como desfazer essa configuração, e voltar pra aquela do tutorial?

  • Os tutoriais que publico são pensados de uma maneira para que você não precise fazer testes com as configurações. Tem como fazer várias coisas diferentes no sistema e nos aplicativos mas acho mesmo que se você tem pouca experiência deveria seguir o rumo proposto.

    Depois de algum tempo quando você tiver mais confiança na operação do servidor então pode-se partir para os testes.

  • Leandro Aguiar

    Ferramenta interessante! Obrigado pela dica!

    Ainda sobre os certificados gerados conforme seu tutorial, apesar dos dois (DOMINIO.COM e FQDN do servidor) funcionarem conforme o esperado, eu notei no log de erro do Nginx a seguinte informação repetidas vezes:

    [error] 19235#0: OCSP_basic_verify() failed (SSL: error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org

    Você já havia se deparado com isso no log?

    Ao pesquisar sobre ela, verifiquei no site do Certbot (https://certbot.eff.org/docs/using.html#where-are-my-certificates) a recomendação de utilizar as seguintes diretivas:

    ssl_certificate /etc/letsencrypt/live/DOMINIO.COM/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DOMINIO.COM/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/DOMINIO.COM/chain.pem;

    No seu tutorial você recomenda algo ligeiramente diferente:

    ssl_certificate /etc/letsencrypt/live/DOMINIO.COM/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/DOMINIO.COM/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/DOMINIO.COM/fullchain.pem;

    Ao configurar as diretivas tanto do DOMINIO.COM quanto do endereço FQDN do servidor conforme o site do Certbot o erro desapareceu.

  • Rodrigo Carvalho

    Luis, estou com problema no meu SSL do FDQN. As vezes o SSL deixar de funcionar e quando tento acessar ele para ter acesso ao painel ISPCONFIG ele me redireciona para o roundcube. O que pode estar acontecendo?

  • “As vezes deixa de funcionar…” Como assim??

    Siga atentamente os procedimentos do tutorial. Já instalei mais de mil servidores usando os passos descritos acima. Vai de boa que está tudo ai..

  • Rodrigo Carvalho

    Boa tarde,

    Luis estou recebendo o seguinte e-mail de erro do Cron:

    Assunto: Cron /usr/bin/certbot renew -q

    Attempting to renew cert from /etc/letsencrypt/renewal/*****.****.**.conf produced an unexpected error: Failed authorization procedure. ***************(http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://****.***.***/.well-known/acme-challenge/********************************************************: ”
    404 Not Found

    404 Not Found
    “. Skipping.

    quando tento acessar /.well-known/acme-challenge/ o nginx retorna erro 404

    location ^~ /.well-known/acme-challenge/ {
    default_type text/plain;
    }

  • Se você colocou essa diretiva no local certo pode ser que por algum outro motivo esteja dando erro ao salvar o conf do vHost inteiro.

    Acesse o diretório: “/etc/nginx/sites-available/” e verifique se o vhost desse site não está com um segundo arquivo lá com a extensão “.err”.

  • Rodrigo Carvalho

    Nenhum .vhost esta com “.err”. E quanto ao erro que Cron esta me informando é na renovação do vps.vhost e tambem da o mesmo erro em um novo certificado.