Como mudar seu site WordPress de HTTP para HTTPS

Quase todos os sites do WordPress devem ser servidos por HTTPS em vez de HTTP, por motivos de segurança e SEO. O conteúdo HTTP não é criptografado, deixando seu site vulnerável, e o Google começou a usar HTTPS como um sinal de classificação em 2014.

Também é necessário para HTTP/2, que oferece velocidades mais altas que o HTTP.

Neste artigo, mostrarei tudo o que você precisa saber para levar um site de HTTP para HTTPS, incluindo a implementação de um certificado SSL e como lidar com quaisquer avisos de conteúdo misto.

Razões para mudar de HTTP para HTTPS

A maioria dos sites na web já são HTTPS neste ponto. Cerca de 95% dos sites estão usando HTTPS, de acordo com o Google Transparency Report . No entanto, ainda é necessário mover sites de HTTP para HTTPS. Posso pensar em pelo menos três casos de uso:

• Mudando de local para ativo: você pode estar usando HTTP para construir um novo site localmente, exigindo uma mudança para HTTPS quando for ao ar.
• Nenhum SSL na preparação do host: se o seu provedor de hospedagem fornecer sites de teste, mas não fornecer um certificado SSL, você precisará converter para HTTPS quando mover o site para produção.
• Sites ao vivo ainda em HTTP: esta é uma ocorrência muito rara hoje em dia, mas surge ocasionalmente. Forneceremos o processo de como fazer isso abaixo, mas você também precisará atualizar o Google Analytics, o Google Search Console, seu URL CDN e todos os links que você controla, como mídia social.

Obter um certificado SSL é apenas parte da batalha. Existem mais alguns ajustes que você precisará para que seu site WordPress funcione bem em HTTPS depois de instalar o certificado:

• Testando o site por HTTPS para garantir que o certificado esteja instalado corretamente
• Atualizando as URLs no banco de dados
• Corrigindo quaisquer avisos de conteúdo misto
• Adicionando redirecionamentos de URLs HTTP para as versões HTTPS de URLs

Por que você precisa de certificados SSL

Certificados SSL devidamente validados garantem que os dados transferidos entre dois sistemas sejam criptografados. Veja como o processo se divide:

1. Um navegador ou servidor tenta se conectar a um servidor da Web e solicita que o servidor se identifique.
2. O servidor web envia uma cópia de seu certificado SSL.
3. O navegador (ou servidor) determina se o certificado foi assinado por uma autoridade de certificação reconhecida.

Resumindo, os certificados SSL autenticam a identidade do seu site, permitindo uma conexão segura. É possível autoassinar

certificados em alguns casos, como quando você precisa de um SSL para desenvolvimento local . Frequentemente, você usará um SSL fornecido pelo seu host.

SSL é a abreviação de Secure Sockets Layer. Curiosamente, o que chamamos de SSL hoje é na verdade um protocolo reformulado: Transport Layer Security (TLS). A tecnologia subjacente e o nome mudaram, mas as iniciais SSL permaneceram.

Escolhendo o SSL certo

Os certificados SSL são categorizados de duas maneiras: níveis de validação e os tipos de domínios que eles protegerão.

Níveis de validação

• Validação de Domínio: Este é o nível mais baixo e, portanto, o mais fácil de obter. Tudo o que diz é que o proprietário é verificado como tendo controle sobre o domínio. O tempo de resposta tende a ser muito rápido, com verificação de e-mail geralmente fornecida em algumas horas. O caso de uso mais comum para um certificado como este é uma pequena empresa que não troca informações com os usuários.
• Validação da organização: Este é um passo à frente da validação de domínio, pois a CA verificará a propriedade do domínio e os detalhes da organização, como nome e localização. Muitas vezes, leva um ou dois dias para que a verificação seja concluída em comparação com certificados validados por domínio.
• Validação Estendida: O pico absoluto da validação do certificado. Além de verificar a propriedade do domínio e os detalhes da organização conforme acima, a CA também verificará a localização física e os detalhes legais da entidade solicitante. Resumindo, o CA faz tudo o que pode para verificar sua existência, exceto que alguns caras venham tirar fotos e verificar sua identidade.

Domínios Seguros

• Domínio único: aplicam-se a apenas um domínio e não funcionam com nenhum outro, nem mesmo com subdomínios desse domínio.
• Curinga: servirão como SSL para um único domínio e todos os seus subdomínios.
• Multi-Domínio: Esses SSLs listam vários domínios em um certificado, abrangendo todos eles e seus subdomínios.

Fazendo a mudança de HTTP para HTTPS

Há algumas coisas que você precisa cuidar antes de começar. Primeiro, você deve considerar fazer um backup do seu site primeiro. Se este for um site ativo, faça um backup primeiro. Existem outros requisitos que você também precisará ter em vigor:

• Certificado(s) SSL
• Verifique as versões HTTPS de serviços e scripts externos
• Certifique-se de que o host e o CDN suportem HTTP/2

Esse último não é tecnicamente necessário, mas você não obterá os benefícios de desempenho do HTTP/2 se não for suportado.

Você também pode querer considerar um plug-in que ofereça suporte à recuperação de compartilhamento, pois a contagem de compartilhamento social em suas postagens e páginas desaparecerá quando você alternar de HTTP para HTTPS.

Uma palavra de alerta em relação ao tráfego: se você estiver mudando um site ativo para HTTPS, não se surpreenda se o tráfego e as classificações de pesquisa caírem um pouco enquanto o Google rastreia novamente o novo site HTTPS.

Adquirindo, implementando e verificando seu certificado SSL

Muitas empresas de hospedagem WordPress oferecem certificados SSL como parte de seu serviço. O processo para solicitá-los varia de host para host (e pode não estar incluído em seu plano de hospedagem), mas geralmente é bastante direto.

Por exemplo, se o seu site for hospedado pelo WP Engine, tudo o que você precisa fazer é fazer login no Portal do usuário do WP Engine , escolher a instalação do WordPress que deseja certificar, selecionar SSL e clicar em Adicionar certificados . Você pode então escolher entre as opções existentes.

Se o seu host não oferece certificados SSL, você também pode comprar um de uma CA, como GoDaddy ou GlobalSign . Você terá que instalar o certificado manualmente. O processo exato para isso varia muito, dependendo da configuração do servidor, mas, no mínimo, você precisará de acesso SSH e/ou painel de controle ao seu servidor, bem como acesso aos registros DNS do seu domínio. Linode e DigitalOcean têm ótimos guias que cobrem isso em detalhes.

Outra opção é configurar o Let’s Encrypt SSL e obter um certificado gratuito dessa forma.

Independentemente do método utilizado, o processo gera uma Solicitação de Assinatura de Certificado (CSR) no servidor onde será instalado e encaminha a solicitação para a CA. O CSR inclui informações pertinentes como nome de domínio, nome da organização, etc. Ele também contém a chave pública que será associada ao certificado. O processo também criará uma chave privada, que não está incluída no CSR. Anote essa chave privada, pois você precisará dela para instalar o certificado.

Se estiver usando um processo manual, você precisará baixar o certificado SSL e o arquivo do pacote de certificados de sua CA e carregá-los em seu servidor. Você precisará editar os arquivos de configuração do servidor para fazer referência ao SSL e aos arquivos do pacote.

Definindo Versões HTTPS de URLs em wp-config.php

Depois de instalar seu certificado SSL, você precisará atualizar seu site para usá-lo. Um hábito que adquiri ao trabalhar com o WordPress ao longo dos anos é que sempre defino a nova URL do site em meu wp-config.php arquivo antes de executar qualquer atualização no banco de dados.

Isso pode ajudar na solução de problemas importantes que possam surgir com a alteração do URL. Por exemplo, o certificado SSL pode não estar configurado corretamente ou pode haver algum código dependente da URL. Se algo assim acontecer, é fácil e rápido remover as linhas do wp-config.php arquivo durante a solução de problemas.

Para fazer isso, edite seu wp-config.php arquivo adicionando as seguintes linhas acima de “Isso é tudo, pare de editar!” Comente:

define( 'WP_HOME', 'https://meusite.com.br' );

define( 'WP_SITEURL', 'https://meusite.com.br' );

Essas linhas têm precedência sobre os valores das opções siteurl e home em seu banco de dados.

Você também pode ajustá-los através do painel do WordPress. Clique em Configurações > Geral e certifique-se de que o endereço do WordPress e o endereço do site estejam configurados para versões HTTPS. Caso contrário, você pode ajustá-los aqui.

Confira algumas páginas em seu site depois de adicioná-las ao seu wp-config.php arquivo. Você pode notar alguns avisos de conteúdo misto devido a imagens ou outros arquivos carregados por HTTP em vez de HTTPS. Vamos consertar isso a seguir.

Corrigindo avisos de conteúdo misto com uma pesquisa e substituição

Os avisos de conteúdo misto ocorrem quando uma página fornece conteúdo HTTPS e HTTP para um navegador. O conteúdo em si pode consistir em JavaScript, CSS, imagens ou qualquer recurso vinculado. Esses avisos significam que a página está apenas parcialmente criptografada e, portanto, algumas das informações podem ser lidas ou modificadas por invasores.

Você pode corrigi-los manualmente, mas geralmente é melhor executar uma pesquisa e substituir usando WP Migrate , WP Migrate Pro ou através da linha de comando com WP-CLI .

O processo manual requer que você visite cada página que está exibindo o aviso de conteúdo misto. Quando estiver lá, inicie as ferramentas de desenvolvimento do seu navegador e clique em Console. Isso deve mostrar exatamente o que está causando esses avisos para que você possa tomar medidas para corrigi-los. Uma das causas mais comuns é um recurso vinculado, como uma imagem, extraída de uma fonte não HTTPS.

Executando uma pesquisa/substituição com WP Migrate

Agora que mudamos o URL principal do site e o URL inicial para HTTPS, ainda precisamos atualizar o restante do conteúdo no banco de dados para usar as versões HTTPS dos URLs.

Podemos fazer isso com o recurso Localizar e substituir do WP Migrate . Abra o WP Migrate no back-end do seu site WordPress, clique em Migrate e, em seguida, clique em Localizar e substituir em “Ferramentas para este site”.

O próximo passo é ajustar nosso localizar e substituir. Eu o configurei para pesquisar todas as tabelas e marquei a opção “Fazer backup de todas as tabelas com o prefixo ‘wp_’” – isso garante que possamos reverter se precisarmos mais tarde.

Em “Opções avançadas”, deixei a opção “Substituir GUIDs” desmarcada. Isso é importante se o seu site já estiver no ar porque a atualização dos GUIDs pode fazer com que qualquer postagem ou página apareça como nova nos leitores de feed. No entanto, recomendo marcar esta caixa se você estiver colocando o site no ar pela primeira vez. Também desmarquei a opção “Excluir transientes” caso haja alguma opção temporária no banco de dados que dependa da URL do site.

Em “Localizar e substituir personalizado”, adicionei a versão HTTP da URL na coluna “Localizar”, com a versão HTTPS na coluna “Substituir”. A última etapa é clicar em Visualizar alterações . Isso iniciará o processo, mostrando as alterações e solicitando que você salve ou cancele cada uma delas. Clicar na seta ao lado do botão “Visualizar alterações” permite alternar a função do botão para “Localizar e substituir”. Isso executará todo o processo sem prompts.

Executando uma Pesquisa/Substituição com WP-CLI

Você também pode executar sua pesquisa e substituição na linha de comando usando o WP-CLI.

Depois de iniciar o WP-CLI, a primeira coisa que você deve fazer é fazer backup do seu banco de dados. Você vai querer ser capaz de reverter quaisquer alterações se algo der errado.

Os comandos WP-CLI sempre seguem um determinado formato, com um comando pai e subcomando, seguidos por parâmetros e opções.

O comando para fazer alterações no banco de dados é wp db. Adicionaremos o export subcomando para fazer backup do banco de dados. O único parâmetro que precisamos adicionar é o caminho do arquivo. Vamos armazená-lo em uma pasta do nosso diretório WordPress para torná-lo um pouco mais difícil para os invasores encontrarem:

wp db export ../mdb_test_backup.sql

A próxima etapa é realmente executar a pesquisa e substituir, usando wp search-replace. Para que isso funcione, precisamos adicionar as opções 'old' e 'new' a este comando. Isso diz ao WP-CLI o que procurar e com o que substituí-lo quando o encontrar. Substitua 'old' (o endereço HTTP) e 'new' (a versão HTTPS) pelos valores corretos no exemplo abaixo, mantendo as aspas simples.

wp search-replace 'antigo' 'novo'

O wp search-replace comando lista muitas outras opções além de old e new, mas veremos apenas mais três por enquanto.

O primeiro é [--dry-run], que diz ao WP-CLI para executar o processo e fornecer um relatório, mas não faz as alterações. Isso é muito útil para verificar se o processo funcionará conforme o esperado.

O segundo é [--report-changed only]. Isso garante que o WP-CLI mostre apenas as alterações, em vez de cada entrada em nosso site WordPress.

Finalmente, vamos inserir --skip-columns=guid. Isso garante que os GUIDs existentes em nosso site WordPress sejam deixados em paz. Você deve omitir esta opção se estiver colocando um site no ar pela primeira vez.

Aqui está o que obtemos quando juntamos tudo:

wp search-replace 'http://mdb.test' 'https://mdb.test' --dry-run --report-changed-only --skip-columns=guid
+------------------+-----------------------+------ --------+------+
| Tabela | Coluna | Substituições | Tipo |
+------------------+-----------------------+------ --------+------+
| wp_postmeta | meta_valor | 3 | PHP |
| wp_posts | post_content | 5 | SQL |
+------------------+-----------------------+------ --------+------+

Atualizando scripts, bibliotecas e seu CDN

Você pode ter scripts e bibliotecas personalizados em seu cabeçalho ou rodapé que precisam ser atualizados. Na maioria dos casos, você pode corrigir isso atualizando o script para apontar para a versão HTTPS.

Se você estiver usando uma rede de distribuição de conteúdo (CDN), talvez seja necessário atualizá-la também. O método real que você usa dependerá do CDN, mas a maioria dos serviços populares fornece guias:

• Microsoft Azure
• Amazon CloudFront
• CDN do Google Cloud

Redirecionando de HTTP para HTTPS

Existem diferentes maneiras de fazer isso, dependendo se você usa Nginx ou Apache em sua pilha. Em ambos os casos, você precisará fazer SSH ou SFTP em seu servidor para fazer qualquer alteração. Além disso, você pode usar um plug-in ou a diretiva Content Security Policy upgrade-insecure-requests. Eu não recomendaria nenhum deles para a maioria dos sites, mas eles podem ajudar a cobrir a lacuna de sites com um grande número de URLs herdados ou até que uma solução mais permanente seja implementada.

Uma palavra de aviso. Nenhuma dessas técnicas fará com que os recursos HTTPS apareçam onde antes não existiam. Tudo o que o redirecionamento faz é garantir que os usuários que tentam acessar o conteúdo HTTP sejam redirecionados para o conteúdo HTTPS. Nos casos em que não há conteúdo HTTPS, os usuários não receberão nada.

Redirecionando com Nginx

Se sua pilha de servidor usa Nginx, você pode redirecionar de HTTP para HTTPS adicionando algumas linhas ao seu nginx.conf arquivo. A localização exata pode variar dependendo se você está usando Nginx Plus ou Open Source, bem como o sistema de pacotes usado para instalar o Nginx. Normalmente, ele está localizado em /etc/nginx , /usr/local/nginx/conf ou /usr/local/etc/nginx.

Você pode copiar e colar as linhas abaixo em seu arquivo de configuração Nginx. Lembre-se de trocar todas as instâncias mdb.testpelo nome do seu servidor.

servidor {
ouvir 80;
server_name mdb.test www.mdb.test;
return 301 https://mdb.test$request_uri;
}

Redirecionando com Apache

Painéis de controle como cPanel e Plesk permitem alterar as configurações que o Apache usa e redirecionar HTTP para HTTPS. Você também pode fazer isso adicionando algumas linhas ao seu .htaccess arquivo Apache.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Certifique-se de adicionar novas linhas fora de quaisquer modificações do WordPress já presentes em seu .htaccess arquivo. Esta seção é marcada com # BEGIN WordPresse  e # END WordPress. Quando terminar, você deve ter algo assim:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Redirecionando com um Plugin

Você também pode usar um plug-in para forçar HTTPS em seu site WordPress. Existem muitas opções , das quais o plug-in Really Simple SSL parece ser o mais popular.

É uma prática recomendada atualizar as URLs em seu banco de dados, em vez de depender de um plug-in. No entanto, os plug-ins podem ser realmente úteis antes de você reservar um tempo para fazer alterações permanentes.

Confira nossa Hospedagem Profissional em WordPress: Hospedagem para sites WordPress com Suporte

Redirecionando com uma política de segurança de conteúdo

Definir uma política de segurança de conteúdo (CSP) é uma maneira útil de gerenciar conteúdo misto em grande escala, tornando-o muito útil para sites grandes com muitos URLs HTTP herdados. Para habilitar os recursos do CSP, você deve incluir o Content-Security-Policy cabeçalho na resposta enviada do seu servidor. Se você não pode acessar seus cabeçalhos, também pode configurá-lo usando uma <meta> tag na <head> seção da página.

Se você tiver acesso ao cabeçalho, basta enviar esta diretiva:

Content-Security-Policy: upgrade-insecure-requests

Isso funciona forçando todos os navegadores que visitam seu site a fazer solicitações seguras em vez de acessar recursos que usam HTTP. Isso evita que o usuário veja o conteúdo inseguro.

Conforme mencionado acima, você também pode usar uma <meta> tag na página <head>:

meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"

Próximas etapas

Com o localizar e substituir concluído e todos os URLs no banco de dados atualizados, você pode remover as atualizações feitas em seu wp-config.php arquivo e verificar algumas páginas no front-end do seu site para garantir que tudo esteja funcionando conforme o esperado.

Se o site não estiver marcado como seguro (geralmente com um ícone de cadeado verde no Chrome ou no Firefox) pelo seu navegador, verifique se ainda há algum aviso de conteúdo misto. Isso acontece quando a página é HTTPS, mas há alguns recursos sendo carregados por HTTP.

Normalmente, você pode identificar esses tipos de avisos indo até o console de javascript do seu navegador e procurando por erros sobre o conteúdo que está sendo carregado por HTTP:

Se você tiver esses erros, o culpado mais comum são os arquivos de tema ou plug-in – às vezes, os links para ativos de tema ou plug-in podem ser codificados e precisarão ser corrigidos.

Conclusão sobre HTTP para HTTPS

Esteja você colocando um site no ar pela primeira vez ou mudando um site existente para HTTPS, as ferramentas disponíveis tornam mais fácil do que nunca implementar seu certificado de segurança e cuidar de seus avisos de conteúdo misto.